Subject: Re: [Extra] CLIENT ID - Next Steps - General Discussion Overview

From: Brandon Long <[email-masked]>
Date: Thu, 2 Aug 2018 16:37:29 -0700

(catching up on email from vacation)

On Mon, Jul 23, 2018 at 3:53 PM Chris Newman <[email-masked]>
wrote:

> On 23 Jul 2018, at 11:27, Michael Peddemors wrote:
> >
> > * It was questioned, is the proper place for this in a SASL mechanism,
> >   vs in the protocol itself, and while our development work and
> > research
> >   show that the advantages for a 'device identifier' to be part of the
> >   protocol/syntax rather than a SASL, and our assertion this will help
> >   in the adoption curve in the industry, it was one of the strongest
> >   points of contention, with the arguments for SASL, was one SASL can
> >   apply to many services, and thus if that argument holds, then maybe
> >   the SASL or a security group would be better for this.  We intend to
> >   argue against this, but the topic alone is key to discussions, so it
> >   requires a separate thread to discuss this.
>
> We have a case where client-id facilities (device-specific token, a
> subset of the client-id problem) were deployed in production using
> custom SASL mechanisms on our server and custom changes to a client. So
> I assert this is a proof-of-concept that SASL is deployable for
> client-id, that it can solve the problem for multiple protocols with one
> specification and shared code (Submission & IMAP), that it comes with an
> extensible capability model for interoperability, and does not break
> interoperability with unmodified clients. Furthermore, no custom changes
> were required to our server to support this since we have a SASL
> abstraction API we support. That means our customers could deploy a
> SASL-based mechanism without requiring a server upgrade, thus
> significantly simplifying deployment. We do not have an API for IMAP
> commands and have no intention of providing one, so our customers will
> not be able to deploy client ID unless it is SASL or there is an IETF
> rough consensus around a non-SASL client-id model for
> submission+imap(+pop+managesieve+jmap+etc).
>
> I consider it unfortunate this use case involved proprietary SASL
> mechanisms so I'd support a standardized mechanism, but we have running
> code showing a SASL approach is deployable and backwards compatible.
>
> I'm aware of another deployed use of client-id like facilities for push
> notifications.
>

Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP is a
form of this in SASL as well, something that we worked on with several
clients (and intended to be taken for standardization) before deciding to
go the OAUTH route that led to OAUTHBEARER eventually.

Just adding the token into the sasl data seemed pretty straightforward.

(not sure if it was mentioned in the presentation or not)

Brandon

---

From: Michael Peddemors <[email-masked]>
Date: Fri, 3 Aug 2018 07:44:22 -0700

Thanks Brandon, for weighing in on this..

And it is good that we seem to have consensus on the following:

* Concept of CLIENTID is worthwhile to pursue
* Standardization is also worthwhile

However, again we should point out.

It isn't that doing this (coding) in a SASL is difficult, we already 
examined this, and found that it limited the scope and abilities that 
CLIENTID offers.  By presenting this at the protocol level, we can 
always pass it to a SASL that wishes to implement it, but by doing it at 
the protocol layer it makes it available to all SASL methods that might 
be developed/extended in the future.

AS well, no use creating a standard that isn't going to see adoption, 
and our team looked at many of the client implementations (opensource) 
as well as several other IMAP server implementations, and realized that 
it is easier to port the protocol implementation, than SASL's across the 
board.

And in some cases, what you want the CLIENTID to interact with, is only 
available at the protocol level, whereas the SASL implementations might 
not have access.

CLIENTID is more than just authentication, as pointed out several times 
already, which is why we call it 'two and 1/2' factor authentication.

The IMAP protocol can handle the verification/sanity and interact with 
external systems, including identifying attack heuristics, and it will 
be available to any SASL which is interested in using it in the 
authentication layer, including legacy SASL and other authentication 
schemes.

	-- Michael --

PS, we are still moving forward with implementation at this level, and 
publishing patches for email clients and other opensource IMAP 
implementations based on our model, so it would be nice to see 
standardization around this model.

So far the only change to our plans has been taking into account the 
opinions of others that we should not use the CID acronym, and consider 
using CLIENTID/DEVICEID instead.

Trying to reach a consensus on opinions on this in the mean time.

On 18-08-02 04:37 PM, Brandon Long wrote:
> On Mon, Jul 23, 2018 at 3:53 PM Chris Newman <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Note that PLAIN-CLIENTTOKEN that gmail still offers for MSA/POP/IMAP is 
> a form of this in SASL as well, something that we worked on with several 
> clients (and intended to be taken for standardization) before deciding 
> to go the OAUTH route that led to OAUTHBEARER eventually.
> 

-- 
"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: "Chris Newman" <[email-masked]>
Date: Fri, 03 Aug 2018 14:02:11 -0700

On 2 Aug 2018, at 16:37, Brandon Long wrote:
> to

Do you have a spec for PLAIN-CLIENTTOKEN?

I hear complaints that OAUTH ends up being not interoperable in a 
scalable way because each client vendor has to perform a manual 
registration step with each service provider. I haven't looked at the 
topic in detail so I may misunderstand something, but that's the 
impression I have. It would be nice to have a standard that actually 
interoperates in a scalable fashion.

		- Chris

---

From: Brandon Long <[email-masked]>
Date: Thu, 9 Aug 2018 14:55:32 -0700

> Do you have a spec for PLAIN-CLIENTTOKEN?

It was basically:
Mechanism: PLAIN-CLIENTTOKEN

Payload: [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token

Example1: \0name\0passwd\0clienttoken
Example2: authzid\0name\0passwd\0clienttoken

SMTP:

S: 220 smtp.example.com ESMTP service ready

C: EHLO client.example.com

S: 250 smtp.example.com says hello

S: 250-ENHANCEDSTATUSCODES

S: 250-8BITMIME

S: 250-AUTH PLAIN PLAIN-CLIENTTOKEN

C: AUTH PLAIN-CLIENTTOKEN YXV0aGNpZO+/vXBhc3N3ZO+/vXNlc3Npb25pZA==
S: 235 2.7.0 Authentication successful

IMAP:

S: * OK example.com IMAP4rev1

C: c CAPABILITY

S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN

S: c OK Completed

C: a AUTHENTICATE PLAIN-CLIENTTOKEN YXV0aGNpZO+/vXBhc3N3ZO+/vXNlc3Npb25pZA==

S: a OK Success

> interoperates in a scalable fashion.

Yes, that's true, or at least was when we were getting OAUTHBEARER through
the RFC process.  Our identity folks were the ones handling the
actual OAUTH specs, and I haven't paid much attention recently.

It looks like dynamic client registration is now an RFC:
https://tools.ietf.org/html/rfc7591
But discovery is still in draft, though active:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-10

I don't know how wide spread adoption is yet, or even if Google has adopted
it.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Thu, 9 Aug 2018 15:21:07 -0700

> be developed/extended in the future.

And some of those SASL methods already include this type of information.
And if
it were useful enough, then it would seem likely to become a standard part
of any future
SASL methods.

> available at the protocol level, whereas the SASL implementations might

Admittedly, we have full access to our stack, so these things are not
complications we
had to deal with.  In fact for us, handling it at the sasl layer meant a
single impl across protocols, as opposed to protocol specific handlers.
Adding the ID as a token to retrieve from the sasl impl to hand to our auth
system was not complicated, and we could have done other things with it if
we'd had a use.

> already, which is why we call it 'two and 1/2' factor authentication.

The list of examples of where else you can use this seems just as easily
to apply to the regular IMAP ID command, modulo the fact that the ID RFC
says DON'T
do that, and that the ID command as a k/v list has both more data and less
consistency.
We did consider some poor mans access control and MDM based on the ID, but
it was never
a high enough priority for the benefit.  I don't know if vendors have that
ask or not.

Today we do offer some of that based on the client-token in the OAUTHBEAER
mechanism,
because of the registration information, the potential to limit / abuse
check creating new
tokens, and because all external access across GSuite is by OAUTH2.  This
means there isn't some special case for IMAP, and tools which touch
multiple APIs and sources can be listed and access controlled singly.

Your use case list also seems to imply that the CLIENTID would have a
structured form, where you can tease apart things to apply those rules, I
don't think your draft does that well.  In particular, I don't see how the
client-id-type is useful.

Brandon

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

---

From: Ned Freed <[email-masked]>
Date: Sat, 11 Aug 2018 10:51:58 -0700 (PDT)

> And if it were useful enough, then it would seem likely to become a standard part
> of any future SASL methods.

There's no need to create more than one new SASL mechanism here. As I described
previously, this can be done at the SASL layer and used in conjunction with
existing SASL mechanisms. The obvious approach is for the client to send the
id, the server to respond with a revised list of SASL mechanisms that can now
be engaged.

> > available at the protocol level, whereas the SASL implementations might

Actually, the opposite is much more likely to be true. Getting the information
to a SASL mechanism may require protocol extensions to whatever the server
uses to talk to the authentication source.

Of course this issue exists to some extent no matter how this is done if
if you want to tie it into existing mechanisms.

> single impl across protocols, as opposed to protocol specific handlers.

Bingo. We're in exactly the same position. And it's multiplied by the need to
change the protocol handling for at least five separate servers. Whereas with
a SASL level mechanism we can do it once and we're done.

> system was not complicated, and we could have done other things with it if

That's good to hear. 

> a high enough priority for the benefit.  I don't know if vendors have that

Given the grosteque situation that's developed around client identifiers
in HTTP, I'm not exactly wild about the prospects for use of this information
outside of authentication.

> multiple APIs and sources can be listed and access controlled singly.

This all looks to still be in the authentication space. The problematic
uses are things like blocking clients.

> client-id-type is useful.

Well, it depends on how you define "useful". Every time you encounter a web
site that says "I don't recognize <browser>, go away", for any value
of <browser> you care to name, you're seening an example of the
"usefulness" of these sorts of mechanisms.

				Ned