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
<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
--------------------------------------------
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.
_______________________________________________
ietf-smtp mailing list
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