idnits 2.17.1 draft-storey-smtp-client-id-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 3, 2018) is 1964 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT W. Storey 3 LinuxMagic 4 Intended Status: Standards Track 5 Expires June 3, 2019 December 3, 2018 7 SMTP Service Extension for Client Identity 8 10 Abstract 12 This document defines an extension for the Simple Mail Transfer 13 Protocol (SMTP) called "CLIENTID" to provide a method for clients to 14 indicate an identity to the server. 16 This identity is an additional token that may be used for security 17 and/or informational purposes, and with it a server may optionally 18 apply heuristics using this token. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ...................................................3 57 2. The CLIENTID Service Extension .................................4 58 3. The CLIENTID Keyword of the EHLO Command .......................4 59 4. The CLIENTID Command ...........................................5 60 5. Formal Syntax ..................................................6 61 6. Discussion .....................................................7 62 6.1 Utility ....................................................7 63 6.2 Use Cases ..................................................7 64 6.3 Other SMTP Identities ......................................8 65 7. Client Identity Types ..........................................8 66 8. Examples .......................................................9 67 8.1 MAC Address as Client Identity .............................9 68 8.2 Client Identity Without a TLS/SSL Session ..................9 69 8.3 Client Identity Leading to Rejection ......................10 70 8.4 Malformed CLIENTID Command ................................10 71 9. Security Considerations .......................................11 72 10. IANA Considerations ...........................................11 73 10.1 SMTP Extension Registration ..............................11 74 11. References ....................................................11 75 11.1 Normative References .....................................11 77 1. Introduction 79 The [SMTP] protocol and its extensions describe methods whereby an 80 SMTP client may provide identity information to an SMTP server. 81 However, every exisitng method for providing an identity is subject 82 to limitations, and none offer a way to identify the SMTP client with 83 absolute confidence. This document defines an additional method to 84 provide an identity that represents the SMTP client with a higher 85 degree of confidence when accessing the SMTP server. 87 Typically SMTP clients are identified by establishing an authorized 88 connection using the [AUTH] SMTP extension. SMTP servers are often 89 subject to malicious clients attempting to use authorized identities 90 not intended for their use (often referred to as a brute- force 91 attack). If such an attack is successful, then the SMTP server may 92 not be able to identify the impersonation and be unable to restrict 93 such a client. While there are ways to identify the source of the 94 SMTP client such as its IP address or EHLO identity, it would be 95 useful if there was an additional way to uniquely identify the client 96 solely across an encrypted channel. 98 Using the CLIENTID extension, an SMTP client can provide a new 99 identity to the server called its "client identity". The client 100 identity can provide unique characteristics about the client 101 accessing the SMTP service and may be combined with existing 102 identification mechanisms 103 in order to identify the client. An SMTP server may then apply 104 additional security policies using this identity such as restricting 105 use of the service to clients presenting recognized client 106 identities, or only allowing use of authorized identities that match 107 previously established client identities. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [KEYWORDS]. 113 2. The CLIENTID Service Extension 115 The following SMTP service extension is hereby defined: 117 (1) The name of this [SMTP] service extension is "Client 118 Identity". 120 (2) The EHLO keyword value associated with this extension is 121 "CLIENTID". 123 (3) The CLIENTID keyword has no parameters. 125 (4) A new [SMTP] verb "CLIENTID" is defined. 127 (5) No parameter is added to any SMTP command. 129 (6) This extension is appropriate for the submission protocol 130 [SUBMIT]. 132 3. The CLIENTID Keyword of the EHLO Command 134 The CLIENTID keyword is used to tell the SMTP client that the SMTP 135 server supports the CLIENTID service extension. Though certain 136 conditions must be met before the CLIENTID keyword can be advertised. 138 Conditions: 140 An SMTP server MUST NOT advertise the CLIENTID keyword in any 141 EHLO responses if the CLIENTID extension support is not 142 enabled. 144 If a connection is not encrypted, an SMTP server SHOULD NOT 145 advertise the CLIENTID keyword in any EHLO response. 147 After a connection is successfully encrypted, an SMTP server 148 MUST advertise the CLIENTID keyword in all EHLO responses. 150 4. The CLIENTID Command 152 The format for the CLIENTID command is: 154 CLIENTID client-id-type client-id-identity 156 Arguments: 158 client-id-type: A string identifying the identity type the 159 client is providing. It MUST be between 1 and 16 alphanumeric 160 characters. 162 client-id-identity: A string identifying the client. It MUST 163 be between 1 and 128 printable characters. 165 Restrictions: 167 A server MUST reject any CLIENTID command that is not well 168 formatted with a 501 reply. 170 An SMTP client MUST only issue the CLIENTID command after the 171 SMTP server advertises the CLIENTID keyword via an EHLO 172 command. An SMTP server MUST reject a CLIENTID command prior 173 to advertsing the CLIENTID keyword via an EHLO command. 175 An SMTP client MUST NOT issue any subsequent CLIENTID commands 176 after a successful CLIENTID command in the same session. An 177 SMTP server MUST reject any subsequent CLIENTID commands 178 after a successful CLIENTID command in the same session with a 179 503 reply. 181 An SMTP client MUST NOT issue a CLIENTID command unless a 182 TLS/SSL session has been negotiated as described in [STARTTLS] 183 or through other means such as over a historical SMTP-SSL 184 connection. A server MUST reject any CLIENTID command sent 185 after establishing an encrypted connection with a 503 reply. 187 An SMTP client MUST issue any CLIENTID commands prior to 188 issuing an [AUTH] command. An SMTP server must reject any 189 CLIENTID command after receiving an [AUTH] command. 191 Several SMTP service extensions such as [AUTH] require that an 192 SMTP session be reset to an initial state under conditions 193 such as after applying a security layer. An SMTP server MUST 194 discard any CLIENTID information after such a reset. 196 Discussion: 198 An SMTP server MAY choose to require that a successful 199 CLIENTID command be issued, or that a particular client type 200 be presented. In such a configuration, the server MAY choose 201 to reject certain commands or sequences of commands issued by 202 a client with a 503 reply. 204 An SMTP server MAY reject any CLIENTID command with a client 205 type that is not supported by the SMTP server with a 504 206 reply. 208 An SMTP server SHOULD NOT reject any CLIENTID command with a 209 client type that is not recognized by the SMTP server. An 210 SMTP server MAY reject during the AUTH command if the CLIENTID 211 command contained a client type that the server does not 212 support with a 504 reply. 214 However, the SMTP server MAY accept and discard any client 215 identity without issuing a rejection even if it does not 216 recognize the client type. The presented information may be 217 useful for analysis. 219 An SMTP server MAY reject any CLIENTID command that contains a 220 client type or client identity that the server chooses not to 221 accept for any reason, such as by policy with a 550 reply. 223 An SMTP server MAY reject any CLIENTID command that contains a 224 client type or client identity that the server has chosen to 225 disable or revoke use of either temporarily or permanently 226 with a 550 reply. 228 In the future there may be a demand for being able to provide 229 multiple CLIENTID commands with different cid types. 231 5. Formal Syntax 233 The following syntax specification uses the Augmented Backus-Naur 234 Form notation as specified in [ABNF]. Non-terminals referenced but 235 not defined below are as defined by [ABNF]. 237 Except as noted otherwise, all alphabetic characters are case- 238 insensitive. 240 client-id-type-char = ALPHA / DIGIT 241 ;; alphanumeric 243 client-id-type = 1*16 client-id-type-char 245 client-id-identity = 1*128 VCHAR 246 ;; any printable US-ASCII character 248 6. Discussion 250 6.1 Utility 252 The utility of the client identity may be seen by considering the 253 following: 255 (1) An SMTP client may be present on a device that does not have a 256 useful domain name or network address, such as a mobile 257 device, so its EHLO identity may be ambiguous; 259 (2) An SMTP client may utilize the same SMTP server with multiple 260 different authorized identities, so an identity that persists 261 across authorized identities is lacking; 263 (3) An authorized identity may make use of multiple discrete 264 devices over different SMTP sessions, so an identity 265 persisting on one device is lacking; 267 (4) The SMTP DATA payload does not need to be inspected for this 268 identity; 270 (5) Connection information, a type of identity, such as network 271 address frequently changes. 273 6.2 Use Cases 275 With the client identity the SMTP server has additional information 276 it may use in its interactions with the client. It may: 278 (1) Restrict use of an authorized identity to a set of client 279 identities, thereby offering an added level of security. For 280 example use of an authorized identity may only be permitted 281 from a single device using the client identity as a form of 282 whitelisting; 284 (2) Identify that the same client identity is used to access 285 multiple authorized identities, and restrict access to the 286 SMTP service. For example a client that has successfully 287 gained access to many authorized identities may be identified 288 through its use of a shared client identity; 290 (3) Retain knowledge of client identities previously presented 291 with an authorized identity, and if an identity not previously 292 seen is used, restrict access to the SMTP service; 294 (4) Require that the SMTP client present a token such as a license 295 key established outside of the SMTP session in order to make 296 use of any authorized identity; 298 (5) Apply different security policies to clients that provide a 299 client identity versus those which do not. For example, 300 provide clients providing such an identity with additional 301 trust. 303 6.3. Other SMTP Identities 305 The [SMTP] protocol and its extensions describe methods whereby an 306 SMTP client may provide identity information to an SMTP server. Some 307 of these identities are listed for contrast: 309 (1) The client connection source provides an IP address associated 310 with the SMTP session; 312 (2) The EHLO command allows a client to identify itself with a 313 domain or address for an SMTP session; 315 (3) The [AUTH] SMTP extension allows the client to establish an 317 authorized identity for an SMTP session; 319 (4) The MAIL command identifies a specific sender for a mail 320 transaction. 322 7. Client Identity Types 324 This document does not specify any identity type that MUST be 325 supported. The MAC and LICENSE types SHOULD be supported, but a 326 server MAY not take any actions using the information. 328 It is envisioned that in the future it will be useful to propose 329 identity types to support. 331 (1) MAC 333 An SMTP client may find it useful to identify the device using 334 which it is establishing the session. This may be done by 335 providing a MAC address. This provides knowledge that 336 persists between different networks and locations yet is 337 stable to a physical client device; 339 (2) LICENSE 341 An SMTP client may find it useful to identify the license key 342 of software it is using. Such licenses are typically crafted 343 such that they are unique and useful to identify a software 344 installation. 346 This document recommends that a server associates a set of flags that 347 describes how the CLIENTID command should be handled for any given 348 client identity type. 350 0 = IGNORE 351 1 = STORE IN SESSION BUT IGNORE (treat as non presented) 352 2 = SYSTEM LOG 353 3 = USER LOG 354 4 = USE FOR AUTHENTICATION 355 5 = USE FOR ALERT WHEN AUTH FAILS 356 6 = USE FOR ALERT WHEN AUTH SUCCEEDS 357 7 = UNUSED 359 8. Examples 361 8.1 MAC Address as Client Identity 363 C: [connection established] 364 S: 220 server.example.com ESMTP ready 365 C: EHLO client.example.net 366 S: 250-server.example.com 367 S: 250-STARTTLS 368 S: 250-AUTH LOGIN 369 C: STARTTLS 370 S: 220 Go ahead 371 C: 372 C & S: 373 C & S: 374 C: EHLO client.example.net 375 S: 250-server.example.com 376 S: 250-AUTH LOGIN 378 S: 250 CLIENTID 379 C: CLIENTID MAC 08:9e:01:70:f6:46 380 S: 250 OK 381 C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ= 382 S: 235 Authentication successful 383 C: MAIL FROM: 384 S: 250 OK 385 C: RCPT TO: 386 S: 250 OK 387 C: DATA 388 S: 354 Ready for message content 389 C: 390 C: . 391 S: 250 OK 392 C: QUIT 393 S: 221 server.example.com Service closing transmission channel 395 8.2 Client Identity Without a TLS/SSL Session 397 C: [connection established over a plaintext connection] 398 S: 220 server.example.com ESMTP ready 399 C: EHLO client.example.net 400 S: 250-server.example.com 401 S: 250-STARTTLS 402 C: CLIENTID MAC 08:9e:01:70:f6:46 403 S: 503 Bad sequence of commands 404 C: MAIL FROM: 405 S: 250 OK 406 C: QUIT 407 S: 221 server.example.com Service closing transmission channel 409 The server rejects use of the CLIENTID command as no TLS/SSL session 410 was yet established. 412 8.3 Client Identity Leading to Rejection 414 C: [connection established over a plaintext connection] 415 S: 220 server.example.com ESMTP ready 416 C: EHLO client.example.net 417 S: 250-server.example.com 418 S: 250-STARTTLS 419 C: STARTTLS 420 S: 220 Go ahead 421 C: 422 C & S: 423 C & S: 425 C: EHLO client.example.net 426 S: 250-server.example.com 427 S: 250 CLIENTID 428 C: CLIENTID MAC 08:9e:01:70:f6:46 429 S: 550 Server policy does not permit your use of this mail system 430 C: QUIT 431 S: 221 server.example.com Service closing transmission channel 433 The server rejects use of the mail system after deciding that the 434 provided client identity does not establish sufficient privileges. 436 8.4 Malformed CLIENTID Command 438 C: [connection established over a plaintext connection] 439 S: 220 server.example.com ESMTP ready 440 C: EHLO client.example.net 441 S: 250-server.example.com 442 S: 250-STARTTLS 443 C: STARTTLS 444 S: 220 Go ahead 445 C: 446 C & S: 447 C & S: 448 C: EHLO client.example.net 449 S: 250-server.example.com 450 S: 250 CLIENTID 451 C: CLIENTID MAC 452 S: 501 Syntax error in parameters or arguments 453 C: QUIT 454 S: 221 server.example.com Service closing transmission channel 456 The server rejects the CLIENTID command as it is not well formed due 457 to there being only a single parameter provided. 459 9. Security Considerations 461 As this extension provides an additional means of communicating 462 information from a client to a server it is clear there is additional 463 information divulged to the server. This may have privacy 464 considerations depending on the client identity type or its contents. 465 For example, it may reveal a MAC address of the device used to 466 communicate with a server that would not previously have been 467 revealed. It is the responsibility of the client to decide whether 468 the benefits outweigh the potential security impacts. 470 As well, while this service extension requires that the identity 471 information only be transmitted over an encrypted channel to reduce 472 the risk of eavesdropping, it does not specify any policies or 473 practices required in the establishment of such a channel, and so it 474 is the responsibility of the client and the server to determine that 475 the communication medium meets their requirements. 477 10. IANA Considerations 479 10.1 SMTP Extension Registration 481 Section 2.2.2 of [SMTP] sets out the procedure for registering a new 482 SMTP extension. 484 This extension will need to be registered. 486 11. References 488 11.1. Normative References 490 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for 491 Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 492 10.17487/RFC5234, January 2008, . 495 [AUTH] Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service 496 Extension for Authentication", RFC 4954, DOI 497 10.17487/RFC4954, July 2007, . 500 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, DOI 502 10.17487/RFC2119, March 1997, . 505 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 506 DOI 10.17487/RFC5321, October 2008, . 509 [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over 510 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 511 February 2002, . 513 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 514 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 515 . 517 Contributors 519 Michael Peddemors 520 LinuxMagic 522 Authors' Addresses 524 William Storey 525 LinuxMagic 526 #405 - 860 Homer St. 527 Vancouver, British Columbia 528 CA V6B 2W5 530 EMail: william@linuxmagic.com 532 Deion Yu 533 LinuxMagic 534 #405 - 860 Homer St. 535 Vancouver, British Columbia 536 CA V6B 2W5 538 EMail: deiony@linuxmagic.com