SMTP Service Extension for Client Identity
draft-storey-smtp-client-id-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Author William Storey 
Last updated 2015-08-17
Stream (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
INTERNET-DRAFT                                                 W. Storey
<draft-storey-smtp-client-id-00.txt>                          LinuxMagic
Intended Status: Standards Track
Expires February 17, 2016                                August 17, 2015

               SMTP Service Extension for Client Identity
                  <draft-storey-smtp-client-id-00.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) 2015 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 February 17, 2016               [Page 1]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

   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 February 17, 2016               [Page 2]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

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 .................................................4
   5. Formal Syntax ...................................................6
   6. Discussion ......................................................6
   6.1 Utility ........................................................6
   6.2 Use Cases ......................................................7
   6.3 Other SMTP Identities ..........................................7
   7. Client Identity Types ...........................................8
   8. Examples ........................................................8
   8.1 MAC Address as Client Identity .................................8
   8.2 Client Identity Without a TLS Session ..........................9
   8.3 Client Identity Leading to Rejection ...........................9
   8.4 Malformed CID Command .........................................10
   9. Security Considerations ........................................10
   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.  This
   document defines an additional such method to provide an identity.

   Each existing identity mechanism available is subject to limitations,
   and none offer a way to identify the SMTP client with absolute
   confidence.

   Typically SMTP clients are identified through the establishment of an
   authorized identity 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 in a manner presented 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 February 17, 2016               [Page 3]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

   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

   An SMTP server includes the CID keyword in its EHLO response to tell
   the SMTP client that the CID service extension is supported.

   The CID keyword has no parameters.

   The SMTP server MUST include the CID keyword in its initial EHLO
   response to indicate it supports the CID service extension.  The
   server MUST also include the CID keyword in any subsequent EHLO
   responses such as a EHLO issued after a successful [STARTTLS]
   negotiation.

4. The CID Command

   CID client-id-type client-id-identity

      Arguments:

Storey, William         Expires February 17, 2016               [Page 4]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

          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:

          The CID command MUST only be issued after a successful EHLO
          command.

          A client MUST NOT issue CID commands containing a client-id-
          type that was successfully completed in the same session.
          After a successful CID command completes, a server MUST reject
          any further CID commands containing the same client-id-type
          parameter with a 503 reply.

          A client MUST NOT issue a CID command unless a TLS session has
          been negotiated as described in [STARTTLS] or through other
          means such as over a historical SMTP-SSL connection.

          A server MUST reject with a 503 reply any CID command sent
          prior to establishing a TLS session.

          A server MUST reject with a 501 reply any CID command that is
          not well formatted.

      Discussion:

          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.  Previously presented
          client identity information MUST be discarded after such a
          reset.  The SMTP client SHOULD present the client identity to
          the server again if it wishes to preserve this information for
          the purposes of logging or security.

          An SMTP server MAY choose to require that a client identity be
          presented, or that a client identity of a particular 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.

          A server MAY reject with a 504 reply any CID command that
          contains a type the server does not support or recognize.
          However, the server may accept and discard any client identity
          without issuing a rejection even if it does not recognize the

Storey, William         Expires February 17, 2016               [Page 5]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

          type.  The presented information may be useful for analysis.

          A server MAY reject with a 550 reply any CID command that
          contains a type or identity that the server chooses not to
          accept for any reason, such as by policy.

          A server MAY reject with a 550 reply any CID command that
          contains a type or identity that the server has chosen to
          disable or revoke use of either temporarily or permanently.

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

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;

Storey, William         Expires February 17, 2016               [Page 6]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

      (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;

      (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;

Storey, William         Expires February 17, 2016               [Page 7]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

      (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.

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 CID
   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: 250 OK
   C: MAIL FROM:<sender@example.net>

Storey, William         Expires February 17, 2016               [Page 8]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

   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 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
   S: 250 CID
   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 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
   S: 250-AUTH PLAIN
   S: 250 CID
   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 PLAIN
   S: 250 CID
   C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=

Storey, William         Expires February 17, 2016               [Page 9]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

   S: 235 2.7.0 Authentication successful
   C: EHLO client.example.net
   S: 250-server.example.com
   S: 250-AUTH PLAIN
   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 the server decides
   that the provided client identity and authorized identity do 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
   S: 250-AUTH PLAIN
   S: 250 CID
   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 PLAIN
   S: 250 CID
   C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
   S: 235 2.7.0 Authentication successful
   C: EHLO client.example.net
   S: 250-server.example.com
   S: 250-AUTH PLAIN
   S: 250 CID
   C: CID MAC
   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 as there
   is only a single parameter provided.

9.  Security Considerations

Storey, William         Expires February 17, 2016              [Page 10]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

   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>.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008, <http://www.rfc-
              editor.org/info/rfc5321>.

Storey, William         Expires February 17, 2016              [Page 11]
INTERNET-DRAFT            SMTP Client Identity           August 17, 2015

   [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

Storey, William         Expires February 17, 2016              [Page 12]