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

From: Brandon Long <[email-masked]>
Date: Wed, 2 Mar 2016 17:04:01 -0800

On Mon, Feb 29, 2016 at 4:57 PM, Michael Peddemors <[email-masked]>
wrote:

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

Vendor servers accepting only vendor clients don't need a public spec, they
can just implement whatever they want.

I'm unclear of the backward compatibility issue, taking our example, the
client either uses PLAIN-CLIENTTOKEN or uses just PLAIN, both are still
supported.

And one could use your CID if you specify that it must be sent prior to
AUTH, for example.  That would allow the challenge to AUTH at the
appropriate time and with the standard status codes, without instead
perhaps reject at MAIL FROM.

SASL also has the concept of challenge-response, which means the client
could do something to gain a CID.

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

software license sounds like another vendor to vendor thing, not an
interoperability thing.

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

I feel that this level of flexibility leads you in the direction of the
IMAP ID command, where there is almost no consensus on what fields there
are and what to present.  That's theoretically fine for ID as there was a
deliberate attempt to limit programmatic usage of the information... but is
annoying to us in terms of dashboard slicing and dicing, and also makes
things much more complicated if you wanted to implement some sort of poor
man's MDM policies for IMAP (because, you're not supposed to).

Without more specification, clients would have to send as many CIDs as they
have in order to increase the likelihood of acceptance, with no feedback.
Without pipelining, that's a lot of round trips, which is especially
annoying for mobile clients (higher latency, more battery usage as the
radio is kept active longer).  Pipelining is of course supported by smtp,
probably should be encouraged in your spec.

Of course, you could include the list of supported CID in the EHLO
response, similar to how AUTH lists the supported SASL mechanisms.

Brandon

---

From: Michael Peddemors <[email-masked]>
Date: Sun, 6 Mar 2016 09:14:04 -0800

(See Embedded Comments)

On 16-03-02 05:04 PM, Brandon Long wrote:
>
>
> On Mon, Feb 29, 2016 at 4:57 PM, Michael Peddemors
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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.
>
>
> Vendor servers accepting only vendor clients don't need a public spec,
> they can just implement whatever they want.

Of course, and we will be implementing some form of this, but we know 
how difficult it can be for vendor's if there is no standard, eg every 
vendor using their own spec.

> perhaps reject at MAIL FROM.

Exactly.  CID MUST come before AUTH in order for it's ability to reduce 
exposure to credentials from dictionary and brute force to take effect.

A client/server interaction where CID is presented, can simply report 
back that the connecting client is not entitled present AUTH 
credentials, rather than exposing the presence of the AUTH (user) 
credentials, or the success/failure of the AUTH (password) presented.

>     Also, advanced MTA's might even let customers 'choose' what type of
>     CID needs to be presented before AUTH attempts are made.
>
>
>     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.
>
>

No, but it provides for the opportunity for an individual who has an 
account on an email server, to be able to store directives based on 
their personal preferences, eg I will only every attempt to log into my 
account using "these" clients, where clients could be identified by 
different factors, one of those might be his various licensed software, 
which might be from various vendors.

Or it could be that the email server vendor prefers to let his customers 
specify by another type of CID, that email clients might support.

> Without more specification, clients would have to send as many CIDs as
> they have in order to increase the likelihood of acceptance, with no
> feedback.  Without pipelining, that's a lot of round trips, which is
> especially annoying for mobile clients (higher latency, more battery
> usage as the radio is kept active longer).  Pipelining is of course
> supported by smtp, probably should be encouraged in your spec.

This is a two parter...
First of all, we are using this forum to help encourage discussion on 
what kinds of CID types can be foreseen, and hopefully that can be made 
succinct and small, but at this time we cannot foresee what others might 
prefer so we elected to allow flexibility by not restricting the types 
at this time.  We do hope that at some time, CID types can be some from 
of registered, or RFC know types, and the list will stay limited in 
scope and number.  Clients of course, would only have to send one CID to 
provide effectiveness, if the server supports that CID type.  Vendor to 
Vendor in theory could have their own spec, but even one agreed CID type 
to start would be effective.

Part two, pipelining is a whole separate can of worms, unrelated to 
this, but many forms of server abuse controls are not pipeline friendly

> response, similar to how AUTH lists the supported SASL mechanisms.

Which is might be the way it has to go, however it could be that the 
fact that any CID is presented, might help to some extent even if the 
type is not recognized by the server.

>
> Brandon
>
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 8 Mar 2016 17:15:51 +0000

> client either uses PLAIN-CLIENTTOKEN or uses just PLAIN, both are still

Agreed. And if some servers would start insisting that the proposed CID
command is always issued before any email can be sent, that would
definitely not be backward compatible.

> could do something to gain a CID.

I think SASL would be the best way to integrate CID-like functionality,
but I appreciate that it might be more work to define. On a plus side, a
SASL mechanism can be reused in other protocols with no changes.

Best Regards,
Alexey