Subject: [ietf-smtp] Discussion of draft-storey-smtp-client-id-01

From: William Storey <[email-masked]>
Date: Mon, 29 Feb 2016 13:39:23 -0800

Hello,

I would like to talk about an SMTP service extension idea and draft.

https://tools.ietf.org/html/draft-storey-smtp-client-id-01

As written, the extension adds a new SMTP command allowing clients to
indicate an identity in the session.

There are several types of identities already:
  - Connection
  - EHLO
  - AUTH
  - MAIL

This one, called client identity, can be used as the identity of the device
or program, rather than an individual or host.

There could be different types. The identity may be something other than a
hostname.

I look at it as an additional data point about the client in the session.

The reason I think this could be useful is to address one of the
limitations in how authenticated SMTP is often used: Clients typically
present only a username and a password. It would be useful to have more
information to protect against brute force and dictionary type attacks.
Having this data could provide flexibility on what clients to accept
authentication from, and possibly allow controlling access based on this
identity.

I am interested in feedback on this idea and the draft.

I've had feedback that it may be better to combine this command with the
CLIENT command written about in draft-ietf-uta-email-deep-01. I think this
would be possible. I thought I would raise the draft as is for feedback
before making changes.

Thank you for your time.

-- 
"Catch the Magic of Linux..."
www.linuxmagic.com
--------------------------------------------
William Storey
Development Services - LinuxMagic Inc.
A Wizard IT company - For More Info
http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of
Wizard Tower TechnoServices Ltd.
"Wizard IT" is a company TradeMark of
Wizard Tower TechnoServices Ltd.
-------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and
intended solely for the use of the individual or entity to which
they are addressed. Please note that any views or opinions presented
in this email are solely those of the author and are not intended
to represent those of the company.

---

From: Brandon Long <[email-masked]>
Date: Mon, 29 Feb 2016 16:19:49 -0800

So, we went down a similar path, and had implemented what we called
"PLAIN-CLIENTTOKEN" as a SASL mechanism.

It's basically the same as a regular SASL PLAIN, but it includes an extra
term for the client token.

This ensures that we have the client token at login time, so that we can
perform the login permission check.  It was also useful since we were
implementing it across multiple protocols.

Ultimately, we instead decided that OAUTHBEARER would be our preferred
mechanism for handling that.

With your spec, sending the CID after login leads to questions about how
you would use it to do your permission checking, when would you say not to
a connection if it didn't include a CID, etc.

I'm also not clear on why you need multiple types of CID tokens.

Our privacy folks would also not be happy with using the MAC address for
this, they would want it to be something that would be cleared by the user
on various use cases, and not necessarily the same across different
accounts so we wouldn't be storing something that could link multiple
accounts together.

Brandon

On Mon, Feb 29, 2016 at 1:39 PM, William Storey <[email-masked]>
wrote:

> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 29 Feb 2016 16:57:42 -0800

Weighing in here.. (See Embedded Comments)

On 16-02-29 04:19 PM, Brandon Long wrote:
> It's basically the same as a regular SASL PLAIN, but it includes an
> extra term for the client token.
>
> you would use it to do your permission checking, when would you say not
> to a connection if it didn't include a CID, etc.

The idea is to be completely backwards compatible with existing 
implementations.  It would be up to the server how it wishes to address 
this, a private server 'might' only accept connections where the CID is 
presented, other servers might find 'opportunistic' ways to utilize 
this, eg different authentication thresholds, or applying trust factors, 
and maybe <sic> apple servers would only allow apple devices.

Also, advanced MTA's might even let customers 'choose' what type of CID 
needs to be presented before AUTH attempts are made.

> I'm also not clear on why you need multiple types of CID tokens.

In order to allow as much flexibility for email server vendors.  Some 
might 'like' a certain type, eg an email client software license.  But 
the benefit is that 'any' form of client ID can be beneficial.

> this, they would want it to be something that would be cleared by the
> user on various use cases, and not necessarily the same across different

And of course, by keeping the CID concept flexible enough, your privacy 
folks might only have your MTA's action on specific CID types, if 
presented. (eg Android Device Identifier), and silently ignore if a 
device presents the MAC as part of CID.  Eg, A Google customer might say 
only Android Devices are allowed to attempt authentications.  Any other 
attempt would not have to reveal the existence of the email for instance.

Does that help understand a bit more?

> Brandon
>
> On Mon, Feb 29, 2016 at 1:39 PM, William Storey <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     www.linuxmagic.com <http://www.linuxmagic.com>
>     604-682-0300 <tel:604-682-0300> Beautiful British Columbia, Canada
>
>     [email-masked] <mailto:[email-masked]>

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.