INTERNET-DRAFT W. Storey <draft-storey-smtp-client-id-05.txt> LinuxMagic Intended Status: Standards Track Expires November 25, 2018 April 25, 2018 SMTP Service Extension for Client Identity <draft-storey-smtp-client-id-05.txt> Abstract This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "CID" to provide a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Storey, William Expires November 25, 2018 [Page 1]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Storey, William Expires November 25, 2018 [Page 2]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 Table of Contents 1. Introduction ...................................................3 2. The CID Service Extension ......................................4 3. The CID Keyword of the EHLO Command ............................4 4. The CID Command ................................................5 5. Formal Syntax ..................................................6 6. Discussion .....................................................7 6.1 Utility ....................................................7 6.2 Use Cases ..................................................7 6.3 Other SMTP Identities ......................................8 7. Client Identity Types ..........................................8 8. Examples .......................................................9 8.1 MAC Address as Client Identity .............................9 8.2 Client Identity Without a TLS/SSL Session ..................9 8.3 Client Identity Leading to Rejection ......................10 8.4 Malformed CID Command .....................................10 9. Security Considerations .......................................11 10. IANA Considerations ...........................................11 10.1 SMTP Extension Registration ..............................11 11. References ....................................................11 11.1 Normative References .....................................11 1. Introduction The [SMTP] protocol and its extensions describe methods whereby an SMTP client may provide identity information to an SMTP server. However, every exisitng method for providing an identity is subject to limitations, and none offer a way to identify the SMTP client with absolute confidence. This document defines an additional method to provide an identity that represents the SMTP client with a higher degree of confidence when accessing the SMTP server. Typically SMTP clients are identified by establishing an authorized connection using the [AUTH] SMTP extension. SMTP servers are often subject to malicious clients attempting to use authorized identities not intended for their use (often referred to as a brute- force attack). If such an attack is successful, then the SMTP server may not be able to identify the impersonation and be unable to restrict such a client. While there are ways to identify the source of the SMTP client such as its IP address or EHLO identity, it would be useful if there was an additional way to uniquely identify the client solely across an encrypted channel. Using the CID extension, an SMTP client can provide a new identity to the server called its "client identity". The client identity can provide unique characteristics about the client accessing the SMTP service and may be combined with existing identification mechanisms Storey, William Expires November 25, 2018 [Page 3]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 in order to identify the client. An SMTP server may then apply additional security policies using this identity such as restricting use of the service to clients presenting recognized client identities, or only allowing use of authorized identities that match previously established client identities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 2. The CID Service Extension The following SMTP service extension is hereby defined: (1) The name of this [SMTP] service extension is "Client Identity". (2) The EHLO keyword value associated with this extension is "CID". (3) The CID keyword has no parameters. (4) A new [SMTP] verb "CID" is defined. (5) No parameter is added to any SMTP command. (6) This extension is appropriate for the submission protocol [SUBMIT]. 3. The CID Keyword of the EHLO Command The CID keyword is used to tell the SMTP client that the SMTP server supports the CID service extension. Though certain conditions must be met before the CID keyword can be advertised. Conditions: An SMTP server MUST NOT advertise the CID keyword in any EHLO responses if the CID extension support is not enabled. If a connection is not encrypted, an SMTP server SHOULD NOT advertise the CID keyword in any EHLO response. After a connection is successfully encrypted, an SMTP server MUST advertise the CID keyword in all EHLO responses. Storey, William Expires November 25, 2018 [Page 4]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 4. The CID Command The format for the CID command is: CID client-id-type client-id-identity Arguments: client-id-type: A string identifying the identity type the client is providing. It MUST be between 1 and 16 alphanumeric characters. client-id-identity: A string identifying the client. It MUST be between 1 and 128 printable characters. Restrictions: A server MUST reject any CID command that is not well formatted with a 501 reply. An SMTP client MUST only issue the CID command after the SMTP server advertises the CID keyword via an EHLO command. An SMTP server MUST reject a CID command prior to advertsing the CID keyword via an EHLO command. An SMTP client MUST NOT issue any subsequent CID commands after a successful CID command in the same session. An SMTP server MUST reject any subsequent CID commands after a successful CID command in the same session with a 503 reply. An SMTP client MUST NOT issue a CID command unless a TLS/SSL session has been negotiated as described in [STARTTLS] or through other means such as over a historical SMTP-SSL connection. A server MUST reject any CID command sent after establishing an encrypted connection with a 503 reply. An SMTP client MUST issue any CID commands prior to issuing an [AUTH] command. An SMTP server must reject any CID command after receiving an [AUTH] command. Several SMTP service extensions such as [AUTH] require that an SMTP session be reset to an initial state under conditions such as after applying a security layer. An SMTP server MUST discard any CID information after such a reset. Discussion: An SMTP server MAY choose to require that a successful CID command be issued, or that a particular client type be presented. In such a configuration, the server MAY choose to reject certain commands or sequences of commands issued by a client with a 503 reply. Storey, William Expires November 25, 2018 [Page 5]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 An SMTP server MAY reject any CID command with a client type that is not supported by the SMTP server with a 504 reply. An SMTP server SHOULD NOT reject any CID command with a client type that is not recognized by the SMTP server. An SMTP server MAY reject during the AUTH command if the CID command contained a client type that the server does not support with a 504 reply. However, the SMTP server MAY accept and discard any client identity without issuing a rejection even if it does not recognize the client type. The presented information may be useful for analysis. An SMTP server MAY reject any CID command that contains a client type or client identity that the server chooses not to accept for any reason, such as by policy with a 550 reply. An SMTP server MAY reject any CID command that contains a client type or client identity that the server has chosen to disable or revoke use of either temporarily or permanently with a 550 reply. Since there is historical precedence for SMTP verbs being at least 4 characters in length and older SMTP servers checking SMTP verbs for this property, an alternate SMTP verb for CID that could be used is "ACID". In the future there may be a demand for being able to provide multiple CID commands with different cid types. 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [ABNF]. Except as noted otherwise, all alphabetic characters are case- insensitive. client-id-type-char = ALPHA / DIGIT ;; alphanumeric client-id-type = 1*16 client-id-type-char client-id-identity = 1*128 VCHAR ;; any printable US-ASCII character Storey, William Expires November 25, 2018 [Page 6]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 6. Discussion 6.1 Utility The utility of the client identity may be seen by considering the following: (1) An SMTP client may be present on a device that does not have a useful domain name or network address, such as a mobile device, so its EHLO identity may be ambiguous; (2) An SMTP client may utilize the same SMTP server with multiple different authorized identities, so an identity that persists across authorized identities is lacking; (3) An authorized identity may make use of multiple discrete devices over different SMTP sessions, so an identity persisting on one device is lacking; (4) The SMTP DATA payload does not need to be inspected for this identity; (5) Connection information, a type of identity, such as network address frequently changes. 6.2 Use Cases With the client identity the SMTP server has additional information it may use in its interactions with the client. It may: (1) Restrict use of an authorized identity to a set of client identities, thereby offering an added level of security. For example use of an authorized identity may only be permitted from a single device using the client identity as a form of whitelisting; (2) Identify that the same client identity is used to access multiple authorized identities, and restrict access to the SMTP service. For example a client that has successfully gained access to many authorized identities may be identified through its use of a shared client identity; (3) Retain knowledge of client identities previously presented with an authorized identity, and if an identity not previously seen is used, restrict access to the SMTP service; (4) Require that the SMTP client present a token such as a license key established outside of the SMTP session in order to make use of any authorized identity; Storey, William Expires November 25, 2018 [Page 7]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 (5) Apply different security policies to clients that provide a client identity versus those which do not. For example, provide clients providing such an identity with additional trust. 6.3. Other SMTP Identities The [SMTP] protocol and its extensions describe methods whereby an SMTP client may provide identity information to an SMTP server. Some of these identities are listed for contrast: (1) The client connection source provides an IP address associated with the SMTP session; (2) The EHLO command allows a client to identify itself with a domain or address for an SMTP session; (3) The [AUTH] SMTP extension allows the client to establish an authorized identity for an SMTP session; (4) The MAIL command identifies a specific sender for a mail transaction. 7. Client Identity Types This document does not specify any identity type that MUST be supported. The MAC and LICENSE types SHOULD be supported, but a server MAY not take any actions using the information. It is envisioned that in the future it will be useful to propose identity types to support. (1) MAC An SMTP client may find it useful to identify the device using which it is establishing the session. This may be done by providing a MAC address. This provides knowledge that persists between different networks and locations yet is stable to a physical client device; (2) LICENSE An SMTP client may find it useful to identify the license key of software it is using. Such licenses are typically crafted such that they are unique and useful to identify a software installation. This document recommends that a server associates a set of flags that describes how the CID command should be handled for any given client identity type. Storey, William Expires November 25, 2018 [Page 8]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 0 = IGNORE 1 = STORE IN SESSION BUT IGNORE (treat as non presented) 2 = SYSTEM LOG 3 = USER LOG 4 = USE FOR AUTHENTICATION 5 = USE FOR ALERT WHEN AUTH FAILS 6 = USE FOR ALERT WHEN AUTH SUCCEEDS 7 = UNUSED 8. Examples 8.1 MAC Address as Client Identity C: [connection established] S: 220 server.example.com ESMTP ready C: EHLO client.example.net S: 250-server.example.com S: 250-STARTTLS S: 250-AUTH LOGIN C: STARTTLS S: 220 Go ahead C: <starts TLS negotiation> C & S: <negotiate a TLS session> C & S: <check result of negotiation> C: EHLO client.example.net S: 250-server.example.com S: 250-AUTH LOGIN S: 250 CID C: CID MAC 08:9e:01:70:f6:46 S: 250 OK C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ= S: 235 Authentication successful C: MAIL FROM:<sender@example.net> S: 250 OK C: RCPT TO:<receiver@example.com> S: 250 OK C: DATA S: 354 Ready for message content C: <body> C: . S: 250 OK C: QUIT S: 221 server.example.com Service closing transmission channel 8.2 Client Identity Without a TLS/SSL Session C: [connection established over a plaintext connection] S: 220 server.example.com ESMTP ready C: EHLO client.example.net S: 250-server.example.com S: 250-STARTTLS Storey, William Expires November 25, 2018 [Page 9]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 C: CID MAC 08:9e:01:70:f6:46 S: 503 Bad sequence of commands C: MAIL FROM:<sender@example.net> S: 250 OK C: QUIT S: 221 server.example.com Service closing transmission channel The server rejects use of the CID command as no TLS/SSL session was yet established. 8.3 Client Identity Leading to Rejection C: [connection established over a plaintext connection] S: 220 server.example.com ESMTP ready C: EHLO client.example.net S: 250-server.example.com S: 250-STARTTLS C: STARTTLS S: 220 Go ahead C: <starts TLS negotiation> C & S: <negotiate a TLS session> C & S: <check result of negotiation> C: EHLO client.example.net S: 250-server.example.com S: 250 CID C: CID MAC 08:9e:01:70:f6:46 S: 550 Server policy does not permit your use of this mail system C: QUIT S: 221 server.example.com Service closing transmission channel The server rejects use of the mail system after deciding that the provided client identity does not establish sufficient privileges. 8.4 Malformed CID Command C: [connection established over a plaintext connection] S: 220 server.example.com ESMTP ready C: EHLO client.example.net S: 250-server.example.com S: 250-STARTTLS C: STARTTLS S: 220 Go ahead C: <starts TLS negotiation> C & S: <negotiate a TLS session> C & S: <check result of negotiation> C: EHLO client.example.net S: 250-server.example.com S: 250 CID C: CID MAC Storey, William Expires November 25, 2018 [Page 10]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 S: 501 Syntax error in parameters or arguments C: QUIT S: 221 server.example.com Service closing transmission channel The server rejects the CID command as it is not well formed due to there being only a single parameter provided. 9. Security Considerations As this extension provides an additional means of communicating information from a client to a server it is clear there is additional information divulged to the server. This may have privacy considerations depending on the client identity type or its contents. For example, it may reveal a MAC address of the device used to communicate with a server that would not previously have been revealed. It is the responsibility of the client to decide whether the benefits outweigh the potential security impacts. As well, while this service extension requires that the identity information only be transmitted over an encrypted channel to reduce the risk of eavesdropping, it does not specify any policies or practices required in the establishment of such a channel, and so it is the responsibility of the client and the server to determine that the communication medium meets their requirements. 10. IANA Considerations 10.1 SMTP Extension Registration Section 2.2.2 of [SMTP] sets out the procedure for registering a new SMTP extension. This extension will need to be registered. 11. References 11.1. Normative References [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc- editor.org/info/rfc5234>. [AUTH] Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <http://www.rfc- editor.org/info/rfc4954>. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc- editor.org/info/rfc2119>. Storey, William Expires November 25, 2018 [Page 11]
INTERNET-DRAFT SMTP Client Identity April 25, 2018 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc- editor.org/info/rfc5321>. [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>. [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>. Contributors Michael Peddemors LinuxMagic Authors' Addresses William Storey LinuxMagic #405 - 860 Homer St. Vancouver, British Columbia CA V6B 2W5 EMail: william@linuxmagic.com Deion Yu LinuxMagic #405 - 860 Homer St. Vancouver, British Columbia CA V6B 2W5 EMail: deiony@linuxmagic.com Storey, William Expires November 25, 2018 [Page 12]