idnits 2.17.1 draft-fenton-identified-mail-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1479. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 13, 2005) is 6916 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (ref. '5') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3447 (ref. '6') (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 1991 (ref. '7') (Obsoleted by RFC 4880) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Fenton 3 Internet-Draft M. Thomas 4 Expires: November 14, 2005 Cisco Systems, Inc. 5 May 13, 2005 7 Identified Internet Mail 8 draft-fenton-identified-mail-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 14, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes extensions to the format of electronic mail 42 messages and a public-key infrastructure to permit verification of 43 the source of messages by either mail transport agents (MTAs) or mail 44 user agents (MUAs). This may be used to implement a policy which, 45 for example, favors the delivery of identified messages over messages 46 lacking signatures or having incorrect signatures. Mechanisms by 47 which signing of messages and verification of signatures can be 48 performed by trusted MTAs, in order to minimize impact on end users, 49 are also presented. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 55 3. Identified Internet Mail Concepts . . . . . . . . . . . . . . 6 56 3.1 Application of Signatures . . . . . . . . . . . . . . . . 8 57 3.2 Verification of Signatures . . . . . . . . . . . . . . . . 8 58 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.1 Header and Verification Syntax . . . . . . . . . . . . . . 10 60 4.2 Relationship to MIME . . . . . . . . . . . . . . . . . . . 11 61 5. The Signature Header . . . . . . . . . . . . . . . . . . . . . 12 62 5.1 IIM Signature Calculation . . . . . . . . . . . . . . . . 12 63 5.1.1 Canonicalization . . . . . . . . . . . . . . . . . . . 13 64 5.2 IIM-Sig Tag Values . . . . . . . . . . . . . . . . . . . . 13 65 5.3 The Verification Header . . . . . . . . . . . . . . . . . 16 66 5.4 Use of From header . . . . . . . . . . . . . . . . . . . . 17 67 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 18 68 6.1 Key Registration . . . . . . . . . . . . . . . . . . . . . 18 69 6.1.1 Key Authorization via KRS . . . . . . . . . . . . . . 19 70 6.1.2 Key Authorization via DNS . . . . . . . . . . . . . . 22 71 6.1.3 Null Key Checks . . . . . . . . . . . . . . . . . . . 23 72 6.1.4 Key Authorization Results . . . . . . . . . . . . . . 23 73 6.2 Policy Options . . . . . . . . . . . . . . . . . . . . . . 25 74 7. Usage examples . . . . . . . . . . . . . . . . . . . . . . . . 27 75 7.1 Simple message transfer . . . . . . . . . . . . . . . . . 27 76 7.2 Outsourced business functions . . . . . . . . . . . . . . 27 77 7.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 27 78 7.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 27 79 7.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 28 80 7.6 Third-party Message Transmission . . . . . . . . . . . . . 29 81 8. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 30 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 83 9.1 Potential Attacks . . . . . . . . . . . . . . . . . . . . 31 84 9.1.1 Key Registration Server Denial-of-Service Attack . . . 31 85 9.1.2 Key Registration Server Stall Tactic . . . . . . . . . 31 86 9.1.3 Misappropriated private key . . . . . . . . . . . . . 32 87 9.1.4 Message Replay Attack . . . . . . . . . . . . . . . . 32 88 9.2 Other Considerations . . . . . . . . . . . . . . . . . . . 33 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 92 12.1 Normative References . . . . . . . . . . . . . . . . . . . 36 93 12.2 Informative References . . . . . . . . . . . . . . . . . . 36 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 95 Intellectual Property and Copyright Statements . . . . . . . . 38 97 1. Introduction 99 Internet users have recently been subjected to a torrent of 100 unsolicited email messages. These generally take two forms: 102 1. Messages originated by "spammers" to send advertising or 103 solicitation, or as part of a confidence scheme or other fraud 105 2. Messages sent automatically by worms and other malware attempting 106 to infect additional systems 108 In both cases, a large proportion of such messages attempt to 109 disguise their true source, in order to frustrate attempts to shut 110 down the spammer, to disguise the identity of the infected system 111 sending the message, or to make it appear that the message came from 112 an entity the recipient trusts (e.g., a bank). Since SMTP permits 113 senders to use any return address they wish, the addition of a 114 signature to messages limits the opportunity of spammers or malware 115 to forge return addresses, and thus provides some degree of 116 accountability for the source of email messages. 118 As currently used, message signatures such as those generated by (for 119 example) PGP are generally used to indicate authorship of the message 120 by a particular individual. The intent here is somewhat different: 121 we want to determine if the sender of the message has authorization 122 (from the administration of the domain) for the use of an email 123 address and associate the signature with the message itself. In 124 order to make the signature transparent to recipients who do not 125 intend to verify it, the signature is encapsulated in the message 126 differently than in a signed PGP message. The public key used to 127 sign the message is included in the header, and its binding with the 128 From or Sender header in the message can be verified with the sending 129 domain. 131 The email identification problem is characterized by extreme 132 scalability requirements. There are currently on the order of 30 133 million domains and a much larger number of individual addresses. It 134 is important to preserve the positive aspects of the current email 135 infrastructure, such as the ability for anyone to communicate with 136 anyone else without introduction. Due to the desire to retain this 137 "any to any" characteristic of email and the (perhaps) lower standard 138 of trust required to accept an email message as compared with, for 139 example, processing a financial transaction, we present an 140 alternative key management model here. 142 What is presented here is not by itself a solution to the spam 143 problem. The intent is to give tools to the recipient to allow the 144 classification and prioritization of desired mail. Since much 145 undesirable mail is currently characterized by forged return 146 addresses, the identification of such messages is a major focus of 147 this effort. Some degree of accountability for the source of email 148 messages will also result, although spammers will still have the 149 ability to operate their own domains and key infrastructure, create 150 large numbers of bogus identities, and sign messages. For this 151 reason, identification of the sender is really a foundation on which 152 accreditation and reputation services can be based. It is hoped that 153 through a combination of such mechanisms, spam, fraudulent, and 154 malware-generated messages may eventually be marginalized to the 155 point that they are not the serious problem they are today. 157 2. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [3]. 163 3. Identified Internet Mail Concepts 165 Identified Internet Mail (IIM) provides a means by which 166 cryptographic signatures can be applied to email messages to 167 demonstrate that the sender of the message was authorized to use a 168 given email address. Message recipients can verify the signature and 169 consult the sender's domain to determine whether the key that was 170 used to sign the message was authorized by that domain for that 171 address. This confirms that the message was sent by an party 172 authorized to use the sender's email address. 174 Just as an email administrator, by creating an email account, gives a 175 user the ability to receive mail addressed to a given address, a 176 means for authorizing the transmission of email messages is needed. 177 The administrator can delegate the use of an address in several ways. 178 The administrator could operate a mail transfer agent (MTA) or mail 179 submission agent (MSA) for the domain that authenticates the sender 180 when accepting a message. This MTA or MSA would typically have a 181 private key that is authorized to send mail for anyone in the domain. 182 Alternatively, the administrator could register a public key for the 183 sender with which, assuming the sender has an MTA or MUA with the 184 appropriate software and the corresponding private key, the sender 185 could sign his own outgoing messages. In the latter case, the 186 private key would typically be authorized for one or more specific 187 addresses that the sender is authorized to use. 189 One central principle used here is that an email address doesn't 190 represent a user's identity. Rather, an email address is something 191 that the owner or administrator of a domain delegates to a user. For 192 example, John Doe may have the email address of jdoe@example.com, but 193 only as long as he remains employed by example.com's owner (or as 194 long as he uses example.com as an ISP). When this relationship 195 changes, John's identity doesn't change, but his authorization to use 196 jdoe@example.com does. For this reason the administrator of 197 example.com, and not John, must have control over the authorization 198 to use the jdoe@example.com address. 200 IIM permits keys to be authorized for specific email addresses 201 ("user-level keys") and/or for all addresses in a domain ("domain- 202 level keys"). User-level keying is needed to support some important 203 use cases. For example: 205 o Domains which want to authorize a partner, such as an advertising 206 provider or other outsourced function, to use a specific address 207 for a given duration. 209 o Domains which want to allow frequent travelers to send messages 210 locally without the need to connect with a particular MSA. 212 o "Affinity" domains (e.g., college alumni associations) which 213 provide forwarding of incoming mail but which do not operate a 214 mail submission agent for outgoing mail. 216 It is expected that many domains will only authorize keys, probably 217 held by outgoing MTAs, which are used for all addresses in the 218 domain. Other domains might allocate a small number of user-level 219 keys, but perform most signing at the domain level. A few domains, 220 such as the affinity domains mentioned above, might do all message 221 signing at the user level. 223 A typical message flow for an IIM message is as follows: 225 +-----------+ 226 | | 227 | | 228 1 | | 229 ======>| sMTA |========== 230 | | = +-----------+ 231 | | = 2 | | 232 +-----------+ ===========>| | 233 3 | rMTA | 5 234 +-----------+ ===========| |==========> 235 | | = | | 236 | | = =======| | 237 | DNS | = = +-----------+ 238 | |<========= = 239 | | = 240 | | = 241 +-----------+ = 242 = 4 243 +-----------+ = 244 | | = 245 | | = 246 | KRS |<======= 247 | | 248 | | 249 +-----------+ 251 Note: This example flow illustrates signing and verification done at 252 MTAs, though there is no requirement that it be placed in any 253 particular element (MUA, MSA, MTA). 255 1. The sending MTA receives mail from a source that it determines is 256 allowed to send mail using its domain's name. 258 2. The sending MTA signs the mail and forwards it to the receiving 259 domain. 261 3. The receiving domain's MTA determines that there is a signature 262 from the responsible domain which asserts that the public key can 263 be verified via a KRS lookup. The MTA performs a DNS lookup to 264 get the address of the sending domain's KRS. This is a key 265 security property: that the sending domain has control of the 266 contents of its DNS. 268 4. The receiving MTA formulates a query back to the sending domain's 269 KRS with the fingerprint of the key that signed the message and 270 the 2822 address of which it would like to determine the 271 authorization. 273 5. The receiving MTA then decides the disposition of the mail based 274 upon the result of the authorization query, typically replacing 275 the IIM-VERIFY header with its opinion and forwarding it along to 276 the receiving MUA. 278 3.1 Application of Signatures 280 Identified Internet Mail (IIM) messages are characterized by the 281 presence of a header, IIM-Sig, in the message. This header contains 282 all of the information required to verify the internal consistency of 283 the message itself, including the signature, the public key 284 corresponding to the private key used to sign the message, options 285 such as the choice of canonicalization and cryptographic algorithms, 286 and information on how to verify the authorization of the supplied 287 public key. 289 Messages may be signed either directly by the author's MUA, by an 290 MSA, or by a subsequent MTA. If the signature is applied by other 291 than the author's MUA, other mechanisms (such as SMTP AUTH, or access 292 control over the network from which messages will be signed) SHOULD 293 be used to ensure that only authorized messages are signed. This is 294 needed to provide some assurance that an attacker will not be able to 295 obtain message signing simply by choosing the right MTA through which 296 to send. 298 3.2 Verification of Signatures 300 An MTA at any point in the message transmission path or a recipient 301 MUA may verify the authorization of the message. This is done by an 302 internal check of the consistency of the message to ensure that the 303 message is properly signed using the included signature and public 304 key. A verifying MTA MUST also check the authorization of the public 305 key to be used with the given email address by consulting either a 306 Key Registration Server (KRS) as described in Section 6.1.1 or DNS as 307 described in Section 6.1.2 at the originating domain, as specified by 308 the signature. This authorization check MAY be performed in parallel 309 with the message consistency check. The message MUST be considered 310 authorized only if the key is authorized and the message passes its 311 consistency check. 313 If no signature is present, or if a message signature fails its 314 consistency check, a "null key" check SHOULD be performed with the 315 originating domain to determine its preference for how the message 316 should be handled. If the null key check indicates that all 317 legitimate messages are signed by the domain, the verifying MTA 318 SHOULD discard unsigned messages. It SHOULD NOT generate a "bounce" 319 message when doing so. 321 MUAs MAY frequently wish to avail themselves of the results of 322 verification by MTAs within their trust domain, because such 323 verifications are more likely to be performed in a timely manner, 324 because the MUA doesn't implement message signature verification, or 325 because the MUA is operating in an offline mode. Verifying MTAs MAY 326 attach an IIM-VERIFY header to the message with the results of 327 message verification to be acted upon by MUAs. MUAs using the 328 information in this header SHOULD act only upon IIM-VERIFY headers 329 applied by a known and trusted entity. In order to avoid the 330 possibility of an MUA acting on a spoofed header sent with the 331 message, verifying MTAs MUST remove any IIM-VERIFY headers already 332 present in messages they process. 334 4. Message Format 336 An identified internet mail message is in the format of a 337 conventional mail message as defined in RFC 2822 [5]. Two new 338 headers, referred to as the signature and the verification header, 339 are defined. 341 4.1 Header and Verification Syntax 343 Identified Internet Mail uses a common encoding for the signature 344 header (IIM-Sig), the verification header (IIM-Verify), as well as 345 for key verification responses from a KRS or from DNS. This consists 346 of a set of tag-value pairs consisting of a tag delimited by a ":" 347 followed by a single value within double quotes separated from the 348 following tag by a ";". Tags may be any number of alphanumeric 349 characters, although at present only single-character tags are 350 defined. A receiver decoding an unknown tag MUST silently discard 351 the tag and value (after incorporating the tag-value pair into the 352 hash calculation for the signature, if applicable). 354 Values are a series of double quoted strings containing either base64 355 text, plain text, or quoted printable text, as defined in RFC 2045 356 [1], section 6.7. The context of the tag will determine the encoding 357 of each value. As of this writing, the only tag which uses the 358 quoted printable format is the "c" (copy) tag. The definition of 359 plain text in this context is ASCII codes 32-126 decimal, with the 360 exception of ASCII 34 (double quote). 362 Each value SHOULD be split into multiple lines as a series of quoted 363 strings to keep the line length less than 78 octets. Decoders MUST 364 interpret multiple quoted strings in a value as if they were all part 365 of a single quoted line. Encoders MUST NOT violate the maximum line 366 length of any particular header line. Decoders MUST ignore strings 367 which span line breaks as the meaning is ambiguous given the way that 368 mail header continuation lines are formed and often reformatted by 369 intermediaries. 371 With the exception of the double quote character (which is converted 372 to =22) and the equals sign (which is converted to =3D), received 373 headers compliant with RFC 2822 [5] will contain no characters which 374 require quoted printable conversion because they will have been 375 encoded as described in RFC 2047 [2]. The conversion of the quote 376 and equals sign is required in order to unambiguously encapsulate the 377 header in a quoted string. For example, the subject line: 379 Subject: Einstein's "E=mc**2" 381 would be encoded as: 383 Subject: Einstein's =22E=3Dmc**2=22 385 Headers with characters which require conversion (perhaps from legacy 386 MTAs which are not RFC 2822 compliant) SHOULD be converted as 387 described in RFC 2047 [2]. Otherwise, the copied header may be 388 converted to quoted printable form as described in section 6.7 of RFC 389 2045 [1], with the additional conversion of double quote and equals 390 sign characters to =22 and =3D respectively. 392 New tags MUST choose whether they are of type plain text, quoted 393 printable, or base64. In general, the plain text type may be used if 394 it is not permissible to have 8 bit and/or syntactically problematic 395 values. Binary forms MUST be encoded as base64, and free form text 396 (e.g., user supplied) MUST be typed as quoted printable. 398 The syntax of tags is as follows: 400 tagvaluepair = 1*ALPHA ":" DQUOTE 1*valuechar DQUOTE 401 *(CRLF 1*WSP DQUOTE 1*valuechar DQUOTE) 402 valuechar = %x20-21 / %x23-7E 403 ;printing characters except double quote 405 4.2 Relationship to MIME 407 With the exception of the canonicalization procedure described in 408 Section 5.1.1, the Identified Internet Mail signing process treats 409 the body of messages as simply a string of characters. IIM messages 410 may be either in plain-text or in MIME format; no special treatment 411 is afforded to MIME content. Message attachments in MIME format are 412 included in the content which is signed, provided the chosen 413 canonicalization (in particular the body length count, if specified) 414 includes the portion of the message containing the attachment. 416 5. The Signature Header 418 The Signature header MUST be included in a message in order for it to 419 be considered an Identified Internet Mail message. It has the 420 syntax: 422 signature = "IIM-Sig:" SP *([CRLF 1*WSP] tagvaluepair ";") 423 tagvaluepair CRLF 425 The signature-text contains a number of fields which represent the 426 signature itself, a public key used to create the signature, and 427 related information. An example of a signature is as follows: 429 IIM-SIG: v:"1"; h:"iim.example.com"; d:"example.com"; z:"home"; 430 m:"krs"; t:"1094844765.338603"; x:"432000"; a:"rsa-sha1"; 431 b:"nofws:1192"; e:"Iw=="; 432 n:"zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBVeaRZ4yWEPclZ/2Mda" 433 "s5Bs9RPWH0BGd3fx6j+txdOXarv4Y8kpMqTexCOMFlDmatpXDXfFj3VI9o4G7" 434 "674gFTasaoPcvEfZCwcBgZD7T6sLZa3RTBUGzZqOshAMRpVek="; 435 s:"Tg67/+k8oltzxIBxN4mevOgbP/+xqxeuT0ugZJ1VoaEm3bJ7JHAOy+X5FEMRF" 436 "/SLZ+GBYIA7wtEmjgbHNuVRnbJQWu732PRbI6UKNGocCEX0TvVdZxFTQzbh3x" 437 "zaEj6BIWx6GYIo8oWoeM3kzZTiip2pPhuvaXu9Ho+3eR81MZ4="; 438 c:"From: John Doe "; 439 c:"Date: Fri, 10 Sep 2004 12:25:51 -0700 (PDT)"; 440 c:"Subject: RE: Lunch" 442 5.1 IIM Signature Calculation 444 All tags and their values in the IIM-Sig header are included in the 445 cryptographic hash with the sole exception of the s: (signature) tag 446 and its value. Tags that are not understood by the receiver are 447 included. The tags and their values are simply concatenated to each 448 other when forming the cryptographic hash in the order they are 449 present in the IIM-Sig line. That is: "v1hiim.example.com[...]" 450 Syntactic markers are NOT included and the value used in the hash is 451 before encoding and after decoding. The final hash algorithm is as 452 follows: 454 TRUNC (SHA1 (SIGTAGVALS, SHA1 (BODY)), 12) 456 where SIGTAGVALS is the encoding described above for the header tags/ 457 values and BODY is the SHA-1 hash of the body of the email itself, 458 including the leading CRLF. Note that SHA-1 value of the body uses 459 the full 16 bytes of the hash (i.e., not truncated). 461 When calculating the hash on base64 and quoted printable values, the 462 hash is taken after the encoding. Likewise, the receiver MUST 463 incorporate the values into the hash before actually decoding the 464 value. 466 5.1.1 Canonicalization 468 In order to minimize the likelihood of signature mismatch due to 469 innocuous message modification, a canonicalization algorithm MAY be 470 specified by the signer of the message. Two canonicalization 471 algorithms are currently defined, "plain" and "nofws". In addition, 472 a body length count MAY be specified to limit the signature 473 calculation to a subset of the body text. 475 Plain canonicalization is effectively the null canonicalization. 476 Bytes of the body are included in the hash without modification. The 477 "nofws" canonicalization removes all whitespace characters in the 478 body and then strips the eighth bit of the data prior to calculating 479 the hash. In this context, whitespace characters are defined as: 481 nofws-whitespace = 1*( SP / HTAB / CR / LF / %x0B / %x0C ) 482 ; last 2 are vertical tab and form feed 484 The body length count allows the signer of a message to permit data 485 to be appended to the end of the body of a signed message. This 486 capability is provided because it is very common for mailing lists to 487 add trailers to messages (e.g., instructions how to get off the 488 list). Until those messages are also signed, the body length count 489 is a useful tool for the receiver since it MAY as a matter of policy 490 accept messages having valid signatures with extraneous data, 491 possibly highlighting the unsigned area. Alternatively, it may strip 492 the extraneous data or reject the message outright. A signer MAY not 493 want to permit appendages to messages and can set the length to "-1" 494 to indicate that all bytes of the body are to be used to calculate 495 the signature. The body length count is made following the 496 canonicalization algorithm; whitespace characters are not counted 497 when using the "nofws" algorithm. 499 Signers that wish to ensure that no modification of any sort may 500 occur MUST specify the "plain" algorithm and a length of -1. 502 Despite the measures described above, some messages, particularly 503 those containing 8-bit data, may be subject to modification in 504 transit invalidating the signature. Messages containing 8-bit data 505 SHOULD be converted to MIME format prior to signing, using a suitable 506 content transfer-encoding such as quoted-printable or base-64. 508 5.2 IIM-Sig Tag Values 510 The tags used in the signature are as follows. The type of each tag 511 is shown in parentheses after its name. 513 a: Algorithm (plain-text). One-way hash and public key algorithm. 514 Currently this MUST be rsa-sha1. This tag MUST be present. 516 b: Body canonicalization (plain-text). This tag informs the receiver 517 of the type of canonicalization used to calculate the signature 518 and the number of bytes in the body of the email included in the 519 cryptographic hash, starting from 0 at the CRLF preceding the 520 body. Its value is of the form "Canon-algorithm:Length". 521 Recognized values of Canon-algorithm are "plain" and "nofws". A 522 length of -1 specifies that all bytes of the body are to be 523 included in the signature calculation. This tag is OPTIONAL and 524 defaults to "plain:-1" if it is absent. 526 c: Copied header (quoted-printable). A copied header is a header 527 which the sender would like to cryptographically sign. No other 528 headers are included into the cryptographic hash. The From header 529 MUST be included; the Sender header MUST also be included if the 530 signature is on behalf of a Sender address which is different from 531 the From address. The copied headers SHOULD also include the 532 Subject and Date headers and MAY include any other headers present 533 at the time of signing at the discretion of the signer. 535 In calculating the hash, the value MUST be encoded as the copied 536 header followed by a colon (":"), followed by a single space, 537 followed by the rest of the value of the copied header. 539 d: Domain of signer (plain-text). This tag denotes the signing 540 domain. It is used to inform the receiver of the appropriate 541 level of address that is considered the authoritative domain in 542 this context. For example, if a message is received from 543 jdoe@eng.example.com, the d: tag might indicate that the domain is 544 example.com or eng.example.com. If this tag does not correspond 545 to the hostname of the From or Sender address or to a parent 546 domain, the signature MUST be ignored. This tag MUST be present. 548 e: Public exponent (base-64). The RSA public exponent of the 549 supplied signing key. This tag MUST be present. 551 h: Signing host (plain-text). The hostname of the applier of the 552 signature. This is purely informational and is not in verifying 553 the signature. This tag is OPTIONAL. 555 m: Method (plain-text). This tag determines which method the signer 556 desires the receiver to use to check the authorization of the 557 supplied public key. This MUST be either "krs" or "dns". This 558 tag is OPTIONAL and defaults to "krs" if it is absent. 560 n: Modulus (base-64). The RSA public modulus of the supplied signing 561 key. Note that the key length is implicit with the number of 562 decoded bits in the modulus. Signers MUST support key lengths of 563 1024 bits and SHOULD support 768 and 1536 bits. Receivers MUST 564 support key lengths of 768, 1024 and 1536 bits. This tag MUST be 565 present. 567 s: Signature (base-64). The RSA signature over the computed one-way 568 hash. The format of the signed message follows PKCS #1v2 with 569 PKCS 1.5 padding. That is, 02||PS||00||M, where PS is the 570 padding, M is the signed hash. If the length of M is greater than 571 12, the first 12 octets MUST be used and the subsequent octets 572 silently ignored. Refer to PKCS #1v2.1 RFC 3447 [6] for the 573 format of PS. This tag MUST be present. 575 t: Timestamp (plain-text). The time that this signature was created. 576 The format is the standard Unix seconds-since-1970 followed by a 577 fractional number which MUST be guaranteed to be unique for this 578 signing key. The intent of the fraction is to guarantee the 579 uniqueness of any given signature at any particular instance. The 580 value is expressed as an unsigned integer in decimal ASCII. This 581 tag MUST be present. 583 v: Version (plain-text). This MUST currently be set to "1". This 584 tag MUST be present, and MUST be the first tag in the IIM-SIG 585 header. 587 x: Signature TTL (plain-text). Signature expiration in seconds- 588 since-1970 format. Signatures MUST NOT be considered valid if the 589 current time at the receiver is past the expiration date. The 590 value is expressed as an unsigned integer in decimal ASCII. This 591 tag MUST be present. 593 z: Signature semantics (plain-text). This tag has two possible 594 values: "home" and "routing". When a signing entity (MTA, MSA, or 595 MUA) wants to assert the origin of a message, it tags the 596 signature with the "home" value. An MTA applying a "home" 597 signature SHOULD perform some sort of access control to filter out 598 mail from outsiders trying to forge mail or SHOULD authenticate 599 the submitter of the message. If the entity merely wants to 600 attest that the mail passed through it on its way to the 601 destination, it uses the "routing" value. Routing signatures are 602 similar to signed Received headers and are of primarily forensic 603 value. This tag SHOULD be present. A missing signature semantics 604 tag should be interpreted as "home". 606 5.3 The Verification Header 608 The verification header is an optional header which MAY be used to 609 convey the verification of a message from an MTA to an MUA or a 610 subsequent MTA within the same trust domain. It has the syntax: 612 signature = "IIM-Verify:" SP *([CRLF 1*WSP] tagvaluepair ";") 613 tagvaluepair CRLF 615 The verification header indicates whether an MTA was able to 616 successfully verify the message according to whatever policies it 617 decides to use. A recipient MUA or MTA MAY decide to rely on the 618 presence of a verification header in applying policy to the message 619 (e.g., moving an unverified message to a lower-priority folder), or 620 it may do such verification locally. 622 The verification header is not cryptographically protected, in order 623 to avoid the need to manage keys for verifying MTAs. The 624 verification header SHOULD be deleted from the header when the 625 message is sent via SMTP outside the trust domain of the sender, and 626 it MUST be discarded if it received from an SMTP peer that is not 627 trusted by the recipient (normally one that is within the recipient's 628 administrative control). There MUST be at most one verification 629 header in a message; MTAs which perform message verification MUST 630 ensure that they either agree with the contents of any existing 631 verification header, or replace it with a new one. 633 An example of a verification header is as follows: 635 IIM-Verify: s:"y"; v:"y"; r:"68"; h:"iim.example.com" 637 The tags and values used by the verification header are as follows: 639 s: Signature (plain-text). The value is "y" if there is a signature 640 line from the sending domain (i.e., the domain suffix of the 641 Sender or From header). Otherwise the value is "n". This tag 642 MUST be present. 644 v: Verify (plain-text). The value is "y" if the home domain's 645 signature is both present and the public key operation verifies 646 correctly. This tag MUST be present. 648 r: Rating (plain-text). The value here is between -127 and 127 with 649 negative values expressing an adverse rating, zero being neutral 650 and positive values indicating a favorable rating. The rating 651 value is completely at the discretion of the entity supplying the 652 IIM-Verify header and MAY take into account many different factors 653 including the rating supplied by the home domain's KRS, local and 654 third party ratings, and any other factors the verifying entity 655 considers relevant. This tag SHOULD be present. 657 h: Host (plain-text). This is the fully qualified domain name of the 658 verifying host. It should be noted that since the IIM-Verify 659 header is not cryptographically protected, users or subsequent 660 MTAs which make use of the IIM-Verify header must independently 661 ensure that it is not subject to tampering. 663 c: Comment (plain-text). This is a free form string intended to 664 convey a human readable comment about the operation. This is 665 typically used to send diagnostic information for failed 666 operations. This tag MAY be present. 668 5.4 Use of From header 670 Identified Internet Mail associates the key in the message with 671 either the Sender or From address of the message. This is done to 672 allow mailing lists which re-originate messages and apply a Sender 673 header (but retain the original From address) to sign the re- 674 originated messages. However, it is the From address that is most 675 commonly seen by the recipient, and it is important that if the 676 Sender address is used to verify the message, that it be made visible 677 to the user. 679 In order to retain the current semantics and visibility of the From 680 header, verifying mail agents SHOULD take steps to ensure that the 681 Sender address is prominently visible to the user if it is used to 682 verify the message and is different from the From address. If MUA 683 implementations that highlight the signed address are not available, 684 this MAY be done by rewriting the From address in a manner which 685 remains compliant with RFC 2822 [5]. If performed, the rewriting 686 SHOULD retrieve the original From header from one of the c: tags of 687 the signature, and include the Sender address (also retrieved from 688 one of the c: tags of the signature) in the display-name of the 689 address. For example: 691 From: "John Q. User via " 693 This sort of address inconsistency is expected for mailing lists, but 694 might be otherwise used to mislead the recipient, for example if a 695 message supposedly from administration@your-bank.com had a Sender 696 address of fraud@badguy.com. 698 6. Key Management 700 In order for these signatures to be meaningful, a method for 701 verifying the validity of the key used to sign the message needs to 702 be available. The PGP [7] approach to this issue of trust is through 703 the use of trusted introducers, where individual keys are signed by 704 others that may be trusted by the user of the public key. However, 705 such a model does not scale well to very large communities of users 706 where several generations of trust would be required. 708 Another approach to this problem would be through the use of X.509 709 certificates. While certificates are attractive for many types of 710 transactions, many consider it undesirable to require that any domain 711 wishing to send signed mail must obtain a certificate through a 712 recognized certificate authority. The ability to quickly and easily 713 revoke the authorization for keys, especially in the case of user- 714 level keys, is also a problem that is most easily solved by 715 consulting the originating domain. 717 In IIM the method of verifying the validity of the key is an online 718 query sent to the signing domain, or to a server designated by that 719 domain. This process is referred to as a key registration or key 720 authorization check. A hash or fingerprint of the key being verified 721 is used to lookup a record in a database operated by the signing 722 domain. Since the use of a fingerprint makes the size of the data 723 required to verify key authorization independent of the length of the 724 key (or certificate), PGP-style signed keys or X.509 certificates 725 could be sent in messages as well, verified using the same 726 mechanisms, and could perhaps be used for other purposes in addition 727 to message signatures. The format for sending such keys and 728 certificates is beyond the scope of this document. 730 6.1 Key Registration 732 In order to receive email messages, domains typically use one or more 733 MX (mail exchanger) resource records to indicate to where mail for 734 that domain should be directed. Similarly, DNS resource records can 735 be used directly or indirectly to verify the authorization of keys 736 used to sign email messages, or to locate one or more hosts which may 737 be considered authoritative to verify the association of keys with 738 email addresses in the domain. 740 A new textual DNS resource record, referred to as a KR record, is 741 defined for publishing and accessing information relating to key 742 registration for a domain. The value 1010 (decimal) is being used 743 for the KR record type in experimental use; this will need to change 744 if and when IANA assigns a record type. An alternative method of 745 publishing and accessing key registration information using TXT 746 records is described in Section 8. 748 To accommodate different deployment needs, two methods of determining 749 the authorization of public keys are defined. The choice of 750 authorization method to be used for a particular message is specified 751 by the signer in the method (m:) tag of the signature. 753 The first method uses HTTP to query a host, referred to as a Key 754 Registration Server (KRS), which is located via a DNS record lookup. 755 This method provides fine-grained control over key authorization; 756 keys may be authorized for use with a list of specific email 757 addresses, and multiple keys may be authorized for a given address. 758 It also takes advantage of a great deal of existing infrastructure 759 used to distribute web services, and can be hosted on an existing web 760 server if desired. 762 The second method of verifying the authorization of a public key is 763 to store the authorization directly in DNS KR records. This method 764 is attractive for domains which have a relatively small number of 765 domain-level keys, because there is no need to operate (or outsource 766 the operation of) a KRS. This method is suitable primarily for keys 767 which are authorized for an entire domain (typically used by outgoing 768 MTAs). 770 Because of limitations imposed by DNS wildcards and the potential 771 privacy issues with storing user email addresses in DNS records, the 772 KRS method SHOULD be used for user-level keys. For domains with only 773 domain-level keys, authorization via either KRS or DNS MAY be used at 774 the option of the sending domain. DNS may be easier for domains that 775 have no externally-accessible Web server on which to run the KRS 776 service; KRS may be easier for domains where the administration of 777 mail services and name service is performed by different groups. 778 Signing agents need only specify the form of key registration used by 779 their domain. Verifying agents MUST support both the KRS and DNS 780 methods. 782 In all cases, the domain referenced for authorization in the 783 signature MUST be either the same as or a parent domain of the 784 address being verified. For example, in order to verify the address 785 tom@eng.example.com, the domain referenced by the signature could be 786 eng.example.com or example.com, but not example2.com. Signatures 787 violating this rule MUST be ignored. 789 6.1.1 Key Authorization via KRS 791 The use of a Key Registration Server (KRS) provides maximum 792 flexibility for domains which support user-level key authorization, 793 and provides administrative separation between management of DNS 794 zones and email authorization. 796 A key registration server confirms (or denies) the binding between 797 the specified email address used by the message and the key used to 798 sign the message. It does so by receiving a query containing the key 799 fingerprint (digest of the public key) and the email address being 800 verified, which will be either the From or Sender address. It 801 returns a value based on the policy of the sending domain as to 802 whether the key is authorized to be used in sending a message from 803 the specified address. 805 When the KRS method has been specified by the sender, the first step 806 for the recipient is to consult its local cache of key 807 authorizations, if any. If a result from a previous key 808 authorization check has been cached and is still valid according to 809 the time-to-live in the cached request, the verifier SHOULD use this 810 result to establish whether the key is authorized for the address. 812 If the local cache check fails, the next step is to locate the 813 address(es) of the domain's KRS(es). This is done by doing a DNS 814 lookup for a KR record for the domain specified in the d: tag of the 815 signature. In order to satisfy this request, the zone file for the 816 domain would contain records such as the following: 818 example.com. IN KR 10 10 378 "v:\"IIM1\"\;s:\"200\"\; 819 k:\"http://www.example.com/KRS/\"\;" 820 example.com. IN KR 10 10 378 "v:\"IIM1\"\;s:\"200\"\; 821 k:\"http://www2.example.com/KRS/\"\;" 823 Once a URI for the KRS query has been obtained, verification of 824 public keys from key registration servers is accomplished via a 825 properly-formatted HTTP GET request. A sample request might be 826 formatted as follows: 828 http://www.example.com/KRS/?domain=example.com 829 &name=john@example.com 830 &keyfp=WDQGpekHKCmKyKWk 832 The fields in the query are as follows: 834 name: The address (From or Sender) being verified. 836 keyfp: The public key fingerprint that was supplied in the IIM-Sig 837 line. The fingerprint is created as follows: create the binary 838 representation of the RSA exponent (e) and modulus (n) and 839 concatenate them as e|n. Run this value through SHA1 over the 840 full length and convert the first 12 bytes of the output of the 841 SHA1 operation to base 64. That is, base64 (TRUNC (SHA1 ((e|n)), 842 12) 844 domain: The domain corresponding to the query to be performed. This 845 is used primarily to allow a single KRS to support multiple 846 domains, with each domain database being independently maintained. 847 This value corresponds to the d: value in the signature being 848 checked; it MUST be the same as or a parent domain of the address 849 associated with the signature. 851 The following are some excerpts from a hypothetical KRS database: 853 #Auth TTL Address Service Key Fingerprint 854 pass 86400 tom@eng.example.com SMTP 073FDD7DD6D6EF6D1413FD7B3C577EFC 855 # Tom's usual address 856 pass 86400 tom@example.com SMTP 073FDD7DD6D6EF6D1413FD7B3C577EFC 857 # Rewriting of Tom's address 858 pass 86400 dick@example.com SMTP 91881749E520D8F53B0B91BBD8963D0D 859 # Dick's PC 860 pass 86400 dick@example.com SMTP 549D8949351DDA4E7C961E0F58727795 861 # Dick's PDA 862 fail 864000 harry@example.com SMTP 8C8252070CA9ED401DD2EE2A7B31A8CF 863 # Harry's stolen PC 864 pass 86400 harry@example.com SMTP 17E64AC44DD5F8891560919D3FC6EA52 865 # Harry's new PC 866 pass 86400 harry@example.com SMTP 073FDD7DD6D6EF6D1413FD7B3C577EFC 867 # Tom is Harry's administrative 868 # assistant, so Harry allows Tom 869 # to originate mail for him. 870 pass 604800 *@example.com SMTP 27985A61447CC8B514A82BFA4597174A 871 # Outgoing MTA key. MTA keys are 872 # less likely to require rapid 873 # revocation, hence the long TTL. 874 pass 86400 nobody@example.com SMTP * 875 # Any key will work for this addr 876 # NOT RECOMMENDED! 878 The above example illustrates much of the motivation behind creation 879 of a network element, the KRS, for key verification. Support for 880 multiple keys per address and multiple addresses per key would 881 require, in general, wildcarding of both the key fingerprint and 882 email address fields, something that is not possible in DNS. Direct 883 key authorization via DNS would also require that users' email 884 addresses be contained in DNS records, which might raise privacy 885 concerns as DNS information is not considered private. Furthermore, 886 the potentially large number and short time-to-live of user-level key 887 authorization records may present loading issues for DNS. 889 The ability to configure multiple key registration servers for a 890 given domain is intended to provide a degree of fault-tolerance and 891 distribution of the key-verification load. The availability 892 requirement for key registration servers is somewhat higher than for 893 mail exchangers (and probably more comparable to that of domain name 894 servers) because real-time access to the key registration servers is 895 often required at the time an email message is received or relayed. 896 Accordingly, each domain defining key registration servers SHOULD 897 define at least two, and they SHOULD be located on different 898 networks. 900 The key registration servers for a domain need to be kept in as close 901 synchronization as possible. In particular, any key revocations that 902 take place MUST be reflected immediately in all key registration 903 servers for the domain. 905 This key management approach requires that only legitimate key-to- 906 address bindings be registered on the key registration servers. Key 907 registration servers MUST use a mechanism that ensures that only 908 authorized users are able to deposit key fingerprints on the server 909 and revoke them. This may involve a mechanism such as an 910 authenticated HTTP exchange that requires the user's password in 911 order to register a public key fingerprint for that user on the 912 server. 914 In order to prevent harvesting of email addresses, KRSes MUST NOT 915 respond with any email address other than that presented in the query 916 or a more general address (for example, when the key fingerprint 917 corresponds to a domain MTA). 919 6.1.2 Key Authorization via DNS 921 In order to accommodate domains with a relatively small number of 922 infrequently changing keys, a domain MAY choose to advertise the 923 authorization of its keys via DNS. In the DNS model, caching of key 924 authorization is provided by DNS itself, rather by a cache locally 925 maintained by the verifier. 927 To check key authorization via DNS, the verifier forms a query for a 928 KR record of the form ., where is the 929 fingerprint of the public key, calculated as described above, 930 expressed in base 64 format. A sample record is as follows: 932 WDQGpekHKCmKyKWk._krs.example.com. KR 933 "v:\"IIM1\"; s:\"200\"; r:\"100\"; t:\"3600\"; m:\"*@example.com\"" 935 Unlike the KRS query method, key authorization via DNS is based only 936 on the key fingerprint itself; the email address is not included in 937 the query. This is done to simplify the query and because DNS does 938 not provide the wildcard functionality to support multiple specific 939 email addresses being authorized for a particular key, as is possible 940 with the KRS method. 942 6.1.3 Null Key Checks 944 In the absence of an IIM signature on a message, it is desirable to 945 provide a means by which the originating domain can express its 946 policy on the signing of messages, and by implication its preference 947 on how unsigned messages SHOULD be handled. This policy is 948 determined through a process known as a Null Key Check. 950 When an unsigned message is received by a verifying MTA or MUA, a 951 null key check SHOULD be performed. This check is performed by 952 forming a DNS query for a KR record in the name of the "domain" in 953 the message. Since there is no IIM-Sig containing a d: tag 954 indicating the responsible domain, the null key check must be 955 performed on the entire right-hand side of the email address of the 956 From header, or in the case of a From header containing multiple 957 addresses, the right-hand side of the email address in the Sender 958 header. A sample DNS record is as follows: 960 example.com. KR "v:\"IIM1\"; s:\"200\"; a:\"fail\"; 961 t:\"864000\"; m:\"*@example.com\"" 963 The results are formatted as shown in Section 6.1.4. Generally, only 964 two of the three possible status values make sense: either the 965 sending domain asserts that the message is to be presumed to be 966 unauthorized, or that the message is of unknown authorization. 968 With only the above null key record in DNS, it might be possible for 969 an attacker to avoid the null key check by using an address in an 970 unknown subdomain of a legitimate domain (e.g., user@foo.example.com 971 in the above example). For this reason, domains publishing a null 972 key policy SHOULD publish both a record for their domain and a 973 wildcard record covering subdomains. For example: 975 example.com. KR "v:\"IIM1\"; s:\"200\"; a:\"fail\"; 976 t:\"864000\"; m:\"*@example.com\"" 977 *.example.com. KR "v:\"IIM1\"; s:\"200\"; a:\"fail\"; 978 t:\"864000\"; m:\"*@example.com\"" 980 6.1.4 Key Authorization Results 982 The KRS and DNS query methods share a common format for the query 983 result with the exception that tagged values from DNS are quoted with 984 single quotes rather than double quotes in order to make them easier 985 to incorporate in typical zone files. Tags and their meanings are as 986 follows: 988 v: Version of the response. Currently this MUST be set to "IIM1". 989 This tag MUST be present, and MUST be the first tag in the 990 response. Responses not beginning with v:"IIM1" MUST be 991 discarded. 993 s: Status. Follows the general convention of SMTP/HTTP status values 994 (i.e., 200, 300, 400, 500 semantics) with the following values 995 defined: 997 200: the lookup succeeded. 998 201: the lookup succeeded, but the keyfp/name combination 999 was not found 1000 500: any permanent failure. 1002 t: Time to live. Responses SHOULD be cached by the verifier so as to 1003 reduce the query/response load back to the KRS. Time to live is 1004 expressed in seconds from when the query was sent. This value is 1005 used only for KRS responses and is ignored if present in DNS 1006 responses. This value is OPTIONAL, and if absent, the response is 1007 not cached by the verifier. 1009 a: Authorization. This tag contains the authorization status of the 1010 given name and key fingerprint association. A value of "pass" 1011 indicates that the KRS/DNS approves of this key fingerprint/name 1012 combination. A value of "fail" indicates the KRS/DNS doesn't 1013 approve, because the key is unknown, unapproved for this name, 1014 revoked, or for any other reason. A value of "Unknown" indicates 1015 that the KRS/DNS doesn't have any specific information one way or 1016 the other. For signed messages "unknown" doesn't make much sense, 1017 but in the case of an unsigned message where the domain cannot 1018 ensure that all of its outgoing mail is signed, "unknown" status 1019 is probably appropriate. The verification in this case SHOULD 1020 treat the mail as if were unsigned. 1022 r: Rating. Like rating in the IIM-Verify, an integer between -127 1023 and 127 which is at the sole discretion of the entity producing 1024 the rating. Normally, revoked keys from the home KRS would be 1025 given a (very) negative rating. This tag is REQUIRED unless the 1026 a: tag is present. 1028 m: Matches. Some key fingerprints may in fact sign for more than the 1029 single address that is present in the query. In order to cut down 1030 trips to the KRS, the Matches field describes with normal Unix 1031 wildcard syntax what address patterns match this key fingerprint. 1032 This tag is REQUIRED. For example, m:"*@example.com" would inform 1033 the cache logic of the requester that future queries from 1034 example.com with this key fingerprint be given the same rating. 1036 k: KRS. Specifies the URL for a KRS to be used to complete the 1037 request. This tag allows the address of a KRS to be specified in 1038 a DNS record, which is referenced as described in Section 6.1.1. 1039 If present, all other tags with the exception of v: and s: will be 1040 ignored. This tag is OPTIONAL and MUST NOT appear in a response 1041 from a KRS. 1043 c: Comment. This is a free form string intended to convey a human 1044 readable comment about the operation. This is typically used to 1045 send diagnostic information for failed operations, etc. This tag 1046 is OPTIONAL. 1048 Note that while the syntax of the matching pattern uses normal unix 1049 wildcard syntax, the semantics of the wildcarding are actually 1050 constrained to be a "longest prefix match" algorithm where the prefix 1051 components are allowed to be either the left hand side of the email 1052 address, or the successive subdomain components. In all cases, the 1053 scope of a Matches value MUST NOT exceed the domain of the KRS or DNS 1054 lookup used to retrieve the authorization. That is, an entity from 1055 example.com cannot say that it matches *@*.com since it is not 1056 authorized to sign for all .com domains. 1058 6.2 Policy Options 1060 Identified Internet Mail by itself introduces no new policy with 1061 respect to handling email. However, the benefit of using IIM lies 1062 with the widespread deployment of policy which encourages the signing 1063 of email and eventually marginalizes unsigned messages. 1065 One place where policy MAY be implemented is at the receiving user. 1066 The user MAY verify the signatures of messages as they are received, 1067 and place unsigned messages in a "bulk mail" or similar folder to be 1068 read (if at all) on a lower-priority basis. This would typically be 1069 done through an enhancement to the mail user agent, probably at the 1070 time messages are downloaded via a protocol such as POP. Since the 1071 user must verify the authorization of all keys not in the user's key 1072 cache, this could lengthen message downloading times, and may present 1073 a problem for transitory users such as those on dial-up lines. 1075 A recipient or intermediate MTA MAY verify the message signatures and 1076 add a verification header to incoming messages. This considerably 1077 simplifies things for the user, who can now use an existing mail user 1078 agent. Most MUAs have the ability to filter messages based on 1079 message headers or content; these filters would be used to implement 1080 whatever policy the user wishes with respect to unsigned mail. 1082 A verifying MTA MAY implement a policy with respect to unsigned mail, 1083 regardless of whether or not it applies the verification header to 1084 signed messages. Separate policies MAY be defined for unsigned 1085 messages, messages with incorrect signatures, and in cases where the 1086 signature cannot be verified, for example if all the key registration 1087 servers are unreachable. Treatment of unsigned messages SHOULD be 1088 based on the results of the null key check described in 1089 Section 6.1.3. 1091 If the verifying MTA is able to verify the public key of the sender 1092 and check the signature on the message as the message is received, 1093 the MTA MAY reject the message with an error such as: 1095 5yx Unsigned messages not accepted 1096 5uv Message signature incorrect 1098 If it is not possible to verify the authorization of the public key 1099 in the message, perhaps because the key registration server is not 1100 available, a temporary failure message could be generated, such as: 1102 4yx Unable to verify signature - key registration server unavailable 1104 7. Usage examples 1106 7.1 Simple message transfer 1108 The above sections largely describe the process of signing and 1109 verifying a message which goes directly from one user to another. 1110 One special case is where the recipient has requested forwarding of 1111 the email message from the original address to another, through the 1112 use of a Unix .forward file or equivalent. In this case the message 1113 is typically forwarded without modification, except for the addition 1114 of a Received header to the message and a change in the Envelope-to 1115 address. In this case, the eventual recipient should be able to 1116 verify the original signature since the signed content has not 1117 changed, and attribute the message correctly. 1119 7.2 Outsourced business functions 1121 Outsourced business functions represent a use case that motivates the 1122 need for user-level keying. Examples of outsourced business 1123 functions are legitimate email marketing providers and corporate 1124 benefits providers. In either case, the outsourced function would 1125 like to be able to send messages using the email domain of the client 1126 company. At the same time, the client may be reluctant to register a 1127 key for the provider that grants the ability to send messages for any 1128 address in the domain. 1130 With user-level keying, the outsourcing company can generate a 1131 keypair and the client company can register the public key for a 1132 specific address such as promotions@example.com. This would enable 1133 the provider to send messages using that specific address and have 1134 them verify properly. The client company retains control over the 1135 email address because it retains the authority to revoke the key 1136 registration at any time. 1138 7.3 PDAs and Similar Devices 1140 PDAs are one example of the use of multiple keys per user. Suppose 1141 that John Doe wanted to be able to send messages using his corporate 1142 email address, jdoe@example.com, and the device did not have the 1143 ability to make a VPN connection to the corporate network. If the 1144 device was equipped with a private key registered for 1145 jdoe@example.com by the administrator of that domain, and appropriate 1146 software to sign messages, John could send IIM messages through the 1147 outgoing network of the PDA service provider. 1149 7.4 Mailing Lists 1151 There is a wide range of behavior in forwarders and mailing lists 1152 (collectively called "forwarders" below), ranging from those which 1153 make no modification to the message itself (other than to add a 1154 Received header and change the envelope information) to those which 1155 may add headers, change the Subject header, add content to the body 1156 (typically at the end), or reformat the body in some manner. 1158 Forwarders which do not modify the body or signed headers of a 1159 message with a valid signature MAY re-sign the message as described 1160 below. Forwarders which make any modification to a message that 1161 could result in its signature becoming invalid SHOULD re-sign using 1162 an appropriate identification (e.g., mailing-list-name@example.net), 1163 but normally they SHOULD do so only for messages which were received 1164 with valid signatures or other indications that the messages being 1165 signed are not spoofed. 1167 Forwarders which wish to re-sign a message MUST apply a Sender header 1168 to the message to identify the address being used to sign the message 1169 and MUST remove any pre-existing Sender header as required by RFC 1170 2822 [5]. The forwarder applies a new IIM-Sig header with the 1171 signature, public key, and related information of the forwarder. 1172 Previously existing IIM-Sig headers SHOULD NOT be removed. 1174 7.5 Affinity Addresses 1176 "Affinity addresses" are email addresses users employ to have an 1177 email address that is independent of any changes in email service 1178 provider they may choose to make. They are typically associated with 1179 college alumni associations, professional organizations, and 1180 recreational organizations with which they expect to have a long-term 1181 relationship. These domains usually provide forwarding of incoming 1182 email, but (currently) usually depend on the user to send outgoing 1183 messages through their own service provider's MTA. They usually have 1184 an associated Web application which authenticates the user and allows 1185 the forwarding address to be changed. 1187 With Identified Internet Mail, affinity domains could use the Web 1188 application to allow users to register their own public keys to be 1189 used to sign messages on behalf of their affinity address. This is 1190 another application that takes advantage of user-level keying, and 1191 domains used for affinity addresses would typically have a very large 1192 number of user-level keys. Alternatively, the affinity domain could 1193 decide to start handling outgoing mail, and could operate a mail 1194 submission agent that authenticates users before accepting and 1195 signing messages for them. This is of course dependent on user's 1196 service provider not blocking the relevant TCP ports used for mail 1197 submission. 1199 7.6 Third-party Message Transmission 1201 Third-party message transmission refers to the authorized sending of 1202 mail by an Internet application on behalf of a user. For example, a 1203 website providing news may allow the reader to forward a copy of the 1204 message to a friend; this is typically done using the reader's email 1205 address. This is sometimes referred to as the "Evite problem", named 1206 after the website of the same name that allows a user to send 1207 invitations to friends. 1209 One way this can be handled is to continue to put the reader's email 1210 address in the From field of the message, but put an address owned by 1211 the site into the Sender field, and sign the message on behalf of the 1212 Sender. A verifying MTA SHOULD accept this and rewrite the From 1213 field to indicate the address that was verified, i.e., From: John Doe 1214 via news@news-site.com . 1216 8. DNS considerations 1218 Any discussion of key management rooted in DNS would be incomplete 1219 without addressing the choice of DNS records for that task. The 1220 architecturally preferred method is to use a new resource record 1221 type, but in practice some resolvers, DNS servers, and firewalls 1222 cannot accommodate a new resource record type. The common workaround 1223 for that problem is the use of an existing record such as TXT, 1224 perhaps with a distinguishing application-dependent prefix in order 1225 to avoid collisions with other uses of TXT records. 1227 As discussed in Section 6.1.3, wildcard DNS records are required to 1228 close a possible attack against the null key check. The use of a 1229 prefix would interfere with the with the required wildcard 1230 functionality. For that reason, null key records cannot use a 1231 distinguishing prefix. This does cause extra collisions with other 1232 uses of the domain's root TXT record space, which could increase the 1233 likelihood that a TXT record lookup for the domain will exceed the 1234 maximum UDP response size. 1236 A compromise using both a new resource record (RR), known as a KR 1237 record, and TXT records is proposed. 1239 Wherever a KR record including a key fingerprint is published, an 1240 identical TXT record SHOULD be published. The _krs prefix is used in 1241 all records with the exception of null key records. This prefix is 1242 used in both KR and TXT records to provide greater consistency 1243 between the corresponding resource records. 1245 The use of the _krs prefix for all other key authorization data other 1246 than the null key record is intended to minimize collisions with 1247 other TXT records and to allow the _krs prefix to be delegated to the 1248 mail administrator, in situations where mail and DNS administration 1249 are done by different organizations. 1251 Verifying agents SHOULD use the KR record if it is available in their 1252 environment. If the KR lookup fails, a lookup for the corresponding 1253 TXT record SHOULD be performed. The intent is to encourage the use 1254 of KR records. However, no migration strategy to eliminate the use 1255 of TXT records has been defined. 1257 For brevity, examples show the use of the KR record only, but 1258 publication and lookup of the corresponding TXT records SHOULD be 1259 performed as well. 1261 9. Security Considerations 1263 Fundamentally, the addition of signatures to email messages is all 1264 about security, although not in the usual way of ensuring the secrecy 1265 of data. 1267 9.1 Potential Attacks 1269 It has been observed that any mechanism that is introduced which 1270 attempts to stem the flow of spam is subject to intensive attack. 1271 Identified Internet Mail needs to be carefully scrutinized to 1272 identify potential attack vectors and the vulnerability to each. 1273 Some of the attacks that have been considered are described in the 1274 following sections. 1276 9.1.1 Key Registration Server Denial-of-Service Attack 1278 Since the key registration servers are distributed (potentially 1279 separate for each domain), the number of servers that would need to 1280 be attacked to defeat this mechanism on an Internet-wide basis is 1281 very large. Nevertheless, key registration servers for individual 1282 domains could be attacked, impeding the verification of messages from 1283 that domain. This is not significantly different from the ability of 1284 an attacker to deny service to the mail exchangers for a given 1285 domain, although it affects outgoing, not incoming, mail. 1287 A variation on this attack is that if a very large amount of mail 1288 were to be sent using spoofed addresses from a given domain, the key 1289 registration servers for that domain could be overwhelmed with 1290 requests. However, given the low overhead of HTTP requests to the 1291 KRSes compared with handling of the email message itself, such an 1292 attack would be difficult to mount. 1294 9.1.2 Key Registration Server Stall Tactic 1296 An attacker trying to "jam" the signature mechanism might set up a 1297 key registration server for a domain they control that responds very 1298 slowly or perhaps not at all. They then send a large number of 1299 messages from that domain, in an attempt to bring the signature 1300 verification mechanism to a crawl and get domains to turn it off. 1301 This could be mitigated by the use of appropriate timeouts on key 1302 lookups and possibly by adapting these timeouts to message load. 1303 Note that it is considerably easier to mitigate this attack when the 1304 signature check is done by the terminating MTA than the MUA because 1305 of the MTA's ability to return a temporary failure when the key can't 1306 be retrieved. 1308 9.1.3 Misappropriated private key 1310 If the private key for a user is resident on their computer and is 1311 not protected by an appropriately secure passphrase, it is possible 1312 for malware to send mail as that user. The malware would, however, 1313 not be able to generate signed spoofs of other senders' addresses, 1314 which would aid in identification of the infected user and would 1315 limit the possibilities for certain types of attacks involving 1316 socially-engineered messages. 1318 A larger problem occurs if malware on many users' computers obtains 1319 the private keys for those users and transmits them via a covert 1320 channel to a site where they may be shared. The compromised users 1321 would likely not know of the misappropriation until they receive 1322 "bounce" messages from messages they are supposed to have sent. Many 1323 users may not understand the significance of these bounce messages 1324 and would not take action. 1326 One countermeasure is to use a passphrase, although users tend to 1327 choose weak passphrases. Nevertheless, the decoded private key might 1328 be briefly available to compromise by malware when it is entered, or 1329 might be discovered via keystroke logging. The added complexity of 1330 entering a passphrase each time one sends a message would also tend 1331 to discourage the use of a secure passphrase. 1333 A somewhat more effective countermeasure is to send messages through 1334 an outgoing MTA that can authenticate the sender and will sign the 1335 message using its key which is normally authorized for all addresses 1336 in the domain. Such an MTA can also apply controls on the volume of 1337 outgoing mail each user is permitted to originate in order to further 1338 limit the ability of malware to generate bulk email. 1340 9.1.4 Message Replay Attack 1342 In this attack, a spammer sends a message to be spammed to an 1343 accomplice, which results in the message being signed by the 1344 originating MTA (presuming that the sender doesn't have a valid 1345 individual key for the domain). The accomplice resends the message, 1346 including the original signature, to a large number of recipients, 1347 possibly by sending the message to many compromised machines that act 1348 as MTAs. The messages, not having been modified by the accomplice, 1349 have valid signatures. 1351 Several techniques for dealing with this type of attack have been 1352 considered. One is to include in the request to the KRS not only the 1353 fingerprint of the signing key but also a fingerprint of the 1354 signature which would allow the KRS to detect, and flag as 1355 unauthorized, the use of the same signature a very large number of 1356 times. This would require the KRS to maintain a cache of signature 1357 fingerprints, and would make caching of key registration data by 1358 verifying MTAs and MUAs impossible. Both of these factors are very 1359 undesirable from a performance standpoint. In addition, some 1360 checking of message date/time fields would need to be introduced in 1361 order to allow aging of the signature cache, where currently there is 1362 no assumption that the sender have a valid real-time clock. 1364 A similar approach is for verifying MTAs and MUAs to cache the 1365 signatures themselves and detect duplications. However, only large 1366 recipient MTAs are likely to process enough of the spam messages in 1367 order to detect the duplications. Furthermore, there are legitimate 1368 use cases involving mail forwarding where the same message might take 1369 different paths to the same MTA, so this can only be applied in cases 1370 where unexpectedly large numbers of duplicate signatures are 1371 received. 1373 Other partial solutions to this problem involve the use of reputation 1374 services to convey the fact that the specific email address is being 1375 used for spam, and that messages from that sender are likely to be 1376 spam. This requires a real-time detection mechanism (such as 1377 detection by the KRS as described above) in order to react quickly 1378 enough. However, such measures might be prone to abuse, if for 1379 example an attacker resent a large number of messages received from a 1380 victim in order to make them appear to be a spammer. 1382 9.2 Other Considerations 1384 At present, a message can be forwarded giving the sender no 1385 indication as to the recipient's actual location (IP address, domain, 1386 or eventual email address) on the Internet. A sender monitoring 1387 queries to its KRS might be able to infer some of this when the 1388 recipient's MTA, or even the actual recipient, checks the 1389 identification of incoming messages. In cases where this may be 1390 sensitive, trusted proxies SHOULD be employed by the recipient and/or 1391 their domain. 1393 10. IANA Considerations 1395 Use of the _krs prefix in TXT records will require registration by 1396 IANA. IANA will also need to allocate a permanent DNS resource 1397 record number for the newly-defined KR record type. 1399 11. Acknowledgements 1401 Dave Rossetti provided much of the original motivation to address 1402 this problem. In addition, thanks to Fred Baker, Mark Baugher, 1403 Patrik Faltstrom, Don Johnsen, Dave Oran, Shamim Pirzada, Sanjay Pol, 1404 Christian Renaud, and Dan Wing for their suggestions and much helpful 1405 discussion around this issue. 1407 12. References 1409 12.1 Normative References 1411 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1412 Extensions (MIME) Part One: Format of Internet Message Bodies", 1413 RFC 2045, November 1996. 1415 [2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 1416 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 1417 November 1996. 1419 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1420 Levels", BCP 14, RFC 2119, March 1997. 1422 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1423 Specifications: ABNF", RFC 2234, November 1997. 1425 [5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1427 [6] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 1428 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 1429 RFC 3447, February 2003. 1431 12.2 Informative References 1433 [7] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 1434 Exchange Formats", RFC 1991, August 1996. 1436 Authors' Addresses 1438 Jim Fenton 1439 Cisco Systems, Inc. 1440 MS SJ-24/2 1441 170 W. Tasman Drive 1442 San Jose, CA 95134-1706 1443 US 1445 Phone: +1 408 526 5914 1446 Email: fenton@cisco.com 1447 Michael Thomas 1448 Cisco Systems, Inc. 1449 MS SJ-9/2 1450 170 W. Tasman Drive 1451 San Jose, CA 95134-1706 1452 US 1454 Phone: +1 408 525 5386 1455 Email: mat@cisco.com 1457 Intellectual Property Statement 1459 The IETF takes no position regarding the validity or scope of any 1460 Intellectual Property Rights or other rights that might be claimed to 1461 pertain to the implementation or use of the technology described in 1462 this document or the extent to which any license under such rights 1463 might or might not be available; nor does it represent that it has 1464 made any independent effort to identify any such rights. Information 1465 on the procedures with respect to rights in RFC documents can be 1466 found in BCP 78 and BCP 79. 1468 Copies of IPR disclosures made to the IETF Secretariat and any 1469 assurances of licenses to be made available, or the result of an 1470 attempt made to obtain a general license or permission for the use of 1471 such proprietary rights by implementers or users of this 1472 specification can be obtained from the IETF on-line IPR repository at 1473 http://www.ietf.org/ipr. 1475 The IETF invites any interested party to bring to its attention any 1476 copyrights, patents or patent applications, or other proprietary 1477 rights that may cover technology that may be required to implement 1478 this standard. Please address the information to the IETF at 1479 ietf-ipr@ietf.org. 1481 The IETF has been notified of intellectual property rights claimed in 1482 regard to some or all of the specification contained in this 1483 document. For more information consult the online list of claimed 1484 rights. 1486 Disclaimer of Validity 1488 This document and the information contained herein are provided on an 1489 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1490 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1491 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1492 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1493 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1496 Copyright Statement 1498 Copyright (C) The Internet Society (2005). This document is subject 1499 to the rights, licenses and restrictions contained in BCP 78, and 1500 except as set forth therein, the authors retain all their rights. 1502 Acknowledgment 1504 Funding for the RFC Editor function is currently provided by the 1505 Internet Society.