Weighing in here.. (See Embedded Comments)
On 16-02-29 04:19 PM, Brandon Long wrote:
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.
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.
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.
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
<william(_at_)linuxmagic(_dot_)com
<mailto:william(_at_)linuxmagic(_dot_)com>> wrote:
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 <http://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 <tel: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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org <mailto:ietf-smtp(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
"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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp