Subject: [Extra] client-id next steps - let's find them a home

From: Bron Gondwana <[email-masked]>
Date: Fri, 20 Jul 2018 13:55:52 +1000

We discussed draft-yu-imap-client-id in today's meeting, and while we
came to the conclusion that it wasn't a document for the working group
to adopt, the problem it's trying to solve is something which the IETF
could help with.
Ned's comment in jabber that didn't make it into the discussion was
something like, it's a cookie, just one the client creates.  That's
pretty much it.  It's basically there are an input to the calculation
that every server has to make on every connection "how much do I believe
that this login is from who it says it's from", or at a more meta level
"how trustworthy is this connection and much do I want to obey its
requests".
At the most trivial level, that's what authentication is - the username
and password (or whatever) gives the server sufficient trust in the
other end of the connection that it allows access to (and maybe
modification of a subset of resources, correlated by the username used).
A general cookie-like "this is a device I have communicated with before"
as an additional input to the server's decision making would be welcomed
by services who see stolen passwords as a common fraud problem, so there
would definitely be appetite for this kind of work.
The open question really is "is this work better suited to a different
group and potentially a different area", and if so "can we help the
authors find that area".
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Ned Freed <[email-masked]>
Date: Fri, 20 Jul 2018 06:28:54 -0700 (PDT)

> something like, it's a cookie, just one the client creates.

Or alternately, one the client is given.

> That's

Right. But given these semantics, one of the things the security folks are
bound to ask is, "Why aren't you using client certificates for this?"

More specificially, a client certificate could be included in the TLS exchange 
and then used for this purpose. It could be self-generated and self-signed,
it could be acquired through the use of ACME or some other protocol - lots
of possibilities there, including the abiity to revoke it.

Of course this would mandate the use of TLS, but I doubt any proposal for
something like this would pass security review without mandatory protection of
the clientid. (I'm going to use the term clientid instead of cid because,
as Barry noted, cid already has a common menaing in the email world, and
this isn't it.)

I will also note that nothing prevents the clientid exchange from occurring in
SASL without restricting the subsequent SASL exchange in any way. The simplest
way to do it woud be to have it be a sort of prefix to the actual SASL method:
Define a CLIENTID method where the client starts the exchange by sending the
<clientid>. If the server like the clientid it would respond with a list of
SASL mechanisms that are now allowed, the client would pick one and proceed to
use it just as if it was starting the SASL exchange at that point.

More sophisticated approaches are possible that don't increase the number of
round trips in most cases. For example, the client could include a prospective
subsequent SASL method and any initial parameter along with the clientid. The
server would then either proceed with the subsequent SASL method, reject the
subsequent SASL method and propose a alternative, or reject the exchange
outright.

It's also possible to include facilities to obtain the initial <clientid>
from the server, update the <clientid>, and so on.

The advantage of doing it this way  is that the security stuff stays at the
security layer and you don't have to add an extension and a new command to
every protocol where you need this. And like it or not, the number of email
protocols where you're going to need this is not going to be less than two:
It's just not acceptable to extend IMAP in this way but not SUBMIT.

The impact on JMAP also needs to be considered.

> would definitely be appetite for this kind of work.

Agreed. That said, the potential for use and abuse beyond this scenario is very
real - we have way too many fully worked examples in the web world where
attempts to do clever stuff based on the supposed client type have led to all
kinds of breakage. (I trust I don't need to provide any examples here.)

This is actually another reason why pushing this down into security
layer is a good idea: It makes it clear what it's supposed to be used for,

> group and potentially a different area", and if so "can we help the

This is a security protocol. That doesn't mean it needs to be done in the
security area, but it will reqiure substantive input from there.

				Ned

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 20 Jul 2018 10:06:31 -0400

> to adopt, the problem it's trying to solve is something which the IETF

In my experience, the IETF is bad at solving generalized problems 
directly, but is better if it looks at a specific application of a 
potentially general problem and worries about generalizing it later. We 
have a specific email (IMAP/SMTP/etc.) use case that has market demand 
for a potentially generalizable problem. I think this WG is a good home 
for discussion of this work until such time as we've specifically 
determined there is another WG that wants to adopt this and is more 
appropriate. We do not have to adopt a document in order for technical 
discussion to be useful and make forward progress. I suggest as a WG we 
dig deeper into three issues with the proposal:

* What are the technical/deployment pros & cons of a separate command 
model verses a SASL-integrated model? I'm considering authoring a 
counter-proposal SASL-based document so we can contrast two specific 
proposals. I'm _very_ interested in specifics of the claimed differences 
in ease of deployment -- that's an important topic for a standards 
community to understand.

* Can/should we specify more semantics about what the client-id (or 
particular flavors of client-id) look like so interoperability between 
servers & clients from different vendors is more feasible based on a 
specification?

* Can we get more precise about the privacy implications and are there 
mitigations for those implications (this may tie into the previous 
question)?

I think a solution to the underlying problem is likely to deploy one way 
or another. We saw what happened with DMARC when the IETF was excluded 
and issues with interoperability were ignored. My opinion is we should 
try to help develop a better proposal and not pass the buck. If we 
decide a SASL-integrated model has rough-consensus after considering 
technical/deployment pros & cons, then we need to work with the Kitten 
WG to agree on which of the two WGs will carry this forward.

If people feel there's a need to have a WG document in order to do work, 
then I would support adoption by this WG of a requirements & 
problem-analysis document for email client-id. I personally think a less 
formal discussion on this list would be a more efficient use of our 
time.

		- Chris

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 21 Jul 2018 02:13:10 +0300

Well, originally I thought this wouldn't be the right place to discuss it, but since people are talking about it, here's what I sent to Deion Yu privately:

I just read through this draft. I think it would be much simpler to implement if it used the existing ID command instead. For example:

a ID ("client-id-type" "uuid" "client-id-token" "23bf83be-aad7-46aa-9e0f-39191ccf402f")

Or alternatively:

a ID ("client-id-uuid" "23bf83be-aad7-46aa-9e0f-39191ccf402f")

It wouldn't require any new capabilities either. Client could simply send this command if it sees ID capability advertised. The servers can then either do something with it or ignore it.

> On 20 Jul 2018, at 6.55, Bron Gondwana <[email-masked]> wrote:
> 
> We discussed draft-yu-imap-client-id in today's meeting, and while we came to the conclusion that it wasn't a document for the working group to adopt, the problem it's trying to solve is something which the IETF could help with.
> 
> Ned's comment in jabber that didn't make it into the discussion was something like, it's a cookie, just one the client creates.  That's pretty much it.  It's basically there are an input to the calculation that every server has to make on every connection "how much do I believe that this login is from who it says it's from", or at a more meta level "how trustworthy is this connection and much do I want to obey its requests".
> 
> At the most trivial level, that's what authentication is - the username and password (or whatever) gives the server sufficient trust in the other end of the connection that it allows access to (and maybe modification of a subset of resources, correlated by the username used).
> 
> A general cookie-like "this is a device I have communicated with before" as an additional input to the server's decision making would be welcomed by services who see stolen passwords as a common fraud problem, so there would definitely be appetite for this kind of work.
> 
> The open question really is "is this work better suited to a different group and potentially a different area", and if so "can we help the authors find that area".
> 
> Bron.
> 
> --
>   [email-masked] <mailto:[email-masked]>
> 
> 
> _______________________________________________
> Extra mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/extra <https://www.ietf.org/mailman/listinfo/extra>

---

From: Michael Peddemors <[email-masked]>
Date: Fri, 20 Jul 2018 17:24:51 -0700

Well first of all, don't you love coming back to the office with all the 
back log after a week.. And I am preparing a fuller response to the 
results of IETF discussion, and I apologize I have not completed it yet 
today.

And I do want to say, that my presentation might have got off on the 
wrong foot, (eg presented a little too much 'fluff' in front of the 
group), please allow that it was my naivete on the process and the late 
scheduling changes, that led me to concentrate on the motivation and 
need for this capability, rather than the 'process' involved for 
acceptance in to the working groups mandate.

And while we agreed that not enough consensus was arrived at to formally 
include this in the working group, we did agree that the discussion 
should take place on the mailing list to enable arguments and opinions 
that can lead to a consensus, and I will create a new separate thread on 
those arguments, and hope to help others understand why, while having 
cross purposes for security related issues that may cross service 
boundaries, based on that it is an IMAP syntax proposal, should at least 
be discussed, if not included.

However, we did get some constructive ideas, and the 'id' idea is one of 
those, and I intended to thread this topic separately.

Since the thread is started, I have changed the subject..

(And yes, while this might support an argument that CID <sic> 'might' 
belong in the working group, see other thread for conversations on that 
topic)

Timo, and others incidental to this list mention this concept (RFC2971)

We did examine this, however RFC 2971 makes EXPLICIT arguments that this 
information provided by ID is NOT to be used for any form of 'flow 
control' ..

"Implementations MUST NOT make operational changes based on the data
    sent as part of the ID command or response.  The ID command is for
    human consumption only, and is not to be used in improving the
    performance of clients or servers."

As we did not know how best to conciliate those cross purposes, so we 
chose an alternative so that we could explicitly allow for actions based 
on the information provided.

Also, the existing RFC does not address the issue of presenting that 
information across a non-secure layer.

* Open to suggestions on how to address those conflicts
* Open to discussions on the cross purposes of these two concepts
* Open to discuss whether 'similar' concept extensions should be 
discussed in this group.
* Should RFC 2971 be revamped to allow for conceptually presenting 
information that can be used for decision making, or are they for 
distinct enough purposes that they should be considered as separate need 
cases.

Thanks for the feedback Timo..

Welcome other comments on this topic only in this thread.

On 18-07-20 04:13 PM, Timo Sirainen wrote:
> Well, originally I thought this wouldn't be the right place to discuss 
> it, but since people are talking about it, here's what I sent to Deion 
> Yu privately:
> 
> I just read through this draft. I think it would be much simpler to 
> implement if it used the existing ID command instead. For example:
> 
> It wouldn't require any new capabilities either. Client could simply 
> send this command if it sees ID capability advertised. The servers can 
> then either do something with it or ignore it.
> 
>> On 20 Jul 2018, at 6.55, Bron Gondwana <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> that every server has to make on every connection "how much do I 
>> believe that this login is from who it says it's from", or at a more 
>> meta level "how trustworthy is this connection and much do I want to 
>> obey its requests".
>>
>> At the most trivial level, that's what authentication is - the 
>> username and password (or whatever) gives the server sufficient trust 
>> in the other end of the connection that it allows access to (and maybe 
>> A general cookie-like "this is a device I have communicated with 
>> before" as an additional input to the server's decision making would 
>> be welcomed by services who see stolen passwords as a common fraud 
>> problem, so there would definitely be appetite for this kind of work.
>>
>> https://www.ietf.org/mailman/listinfo/extra
> 
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

-- 
"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: Bron Gondwana <[email-masked]>
Date: Sat, 21 Jul 2018 23:39:48 +1000

I also suggested that too Michael the first time we talked. Apparently
the issue was with use before/after authentication.
Certainly in FastMail's case, ID before auth would be in nginx rather
than Cyrus, so we don't even advertise it until after auth because we
want to log it on the backend.
Bron.

On Sat, Jul 21, 2018, at 09:13, Timo Sirainen wrote:
> Yu privately:> 
> implement if it used the existing ID command instead. For example:> 
> a ID ("client-id-type" "uuid" "client-id-token" "23bf83be-aad7-46aa-9e0f-
> 39191ccf402f")> 
> Or alternatively:
> 
> then either do something with it or ignore it.> 
>> On 20 Jul 2018, at 6.55, Bron Gondwana
>> <[email-masked]> wrote:>> 
>> came to the conclusion that it wasn't a document for the working
>> group to adopt, the problem it's trying to solve is something which
>> the IETF could help with.>> 
>> obey its requests".>> 
>> in the other end of the connection that it allows access to (and
>> maybe modification of a subset of resources, correlated by the
>> username used).>> 
>> problem, so there would definitely be appetite for this kind of work.>> 
>> The open question really is "is this work better suited to a
>> different group and potentially a different area", and if so "can we
>> help the authors find that area".>> 
>> Bron.
>> 
>> --
> _________________________________________________
> Extra mailing list
> [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 22 Jul 2018 00:14:47 +1000

On Sat, Jul 21, 2018, at 10:24, Michael Peddemors wrote:
> group), please allow that it was my naivete on the process and
> the late> scheduling changes, that led me to concentrate on the motivation and

This group is very technical, and most of the people who spoke up are
people who will have to implement this in a server or client, and
maintain the infrastructure it's going into, some of which is quite
different from the infrastructure of the systems you use or have worked
on.  This group of people understands issues pretty quickly, so we
jumped directly to the process of not only deploying this in the first
place, but maintaining it and the impact on the rest of the ecosystem.
> And while we agreed that not enough consensus was arrived at to
> formally> include this in the working group, we did agree that the discussion
> should take place on the mailing list to enable arguments and opinions> that can lead to a consensus, and I will create a new separate
> thread on> those arguments, and hope to help others understand why, while having> cross purposes for security related issues that may cross service
> boundaries, based on that it is an IMAP syntax proposal, should
> at least> be discussed, if not included.

I would caution against getting caught up on the "something needs to be
done", "this is something", "therefore we must do this".  I felt there
was a fair degree of "this is a real issue that could do with being
solved" in the room, but it doesn't necessarily flow that it must be
solved at the IMAP syntax level.
> However, we did get some constructive ideas, and the 'id' idea
> is one of> those, and I intended to thread this topic separately.
> 
> (And yes, while this might support an argument that CID <sic> 'might'> belong in the working group, see other thread for conversations on
> that> topic)
> 
> Timo, and others incidental to this list mention this concept
> (RFC2971)> 
> We did examine this, however RFC 2971 makes EXPLICIT arguments
> that this> information provided by ID is NOT to be used for any form of 'flow
> control' ..
> 
>     sent as part of the ID command or response.  The ID command is for>     human consumption only, and is not to be used in improving the

Of course if we were to update RFC2971, that would be something that
could be considered.  We can change anything that's within charter and
passes expert review from the rest of the IETF.
And let's be honest, not everybody obeys that "MUST NOT" anyway...

https://github.com/cyrusimap/cyrus-imapd/commit/b61e07ed212ae20eb1f8f57de7cee6e7f1c2c839
It was a choice between search being unusable on iOS and search being
quite nice on iOS, but not strictly standards compliant, while not
making search non-standard for every other IMAP user.
> distinct enough purposes that they should be considered as
> separate need> cases.

I do agree that there are downsides to extending ID rather than having
a new command.  CLIENTID would be very simple for me to implement in
Cyrus, and I expect it would be relatively easy to implement in Nginx
as a value passed through to the authentication engine as well.  That's
not nothing.
We may also need to discuss how ISPs which still don't enforce TLS
because they are afraid of support calls and losing customers are going
to handle deploying this extension.  The justification that we need this
because ISPs are still allowing plain text passwords seems to conflict
with the idea that those customers who can't be migrated to TLS are
going to upgrade to clients which support any new standard we propose.
So if we're doing this just to help those ISPs, it might end up being a
futile exercise.
Bron.

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2018 11:33:12 -0400

>of possibilities there, including the abiity to revoke it.

This is a very good point.  Clients could start sending self-signed
client certs in the TLS handshalke today with no protocol changes at
all.  Hmmn.

There is the usual crudware problems since I would guess there is too
much code that would barf on that, either fail because it's not
expecting a cert, or never debugged "this cert isn't signed by a CA I
trust therefore it is bad."

I have seen code that uses client certs signed by a private CA for
submit authorization.  That doesn't necessarily conflict except that
if I have two MUAs I might put the same cert on both of them so the
server can't tell them apart.  That's probably not a problem until it
is, e.g., one MUA is the phone I just lost.  Yes, I realize that the
proper approach is to generate separate requests on each device and
sign them separately.

R's,
John

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 23 Jul 2018 13:59:09 -0400

On 20 Jul 2018, at 20:24, Michael Peddemors wrote:
> Well first of all, don't you love coming back to the office with all 
> the back log after a week.. And I am preparing a fuller response to 
> the results of IETF discussion, and I apologize I have not completed 
> it yet today.
>
> group), please allow that it was my naivete on the process and the 
> late scheduling changes, that led me to concentrate on the motivation 
> and need for this capability, rather than the 'process' involved for 
> formally include this in the working group, we did agree that the 
> discussion should take place on the mailing list to enable arguments 
> and opinions that can lead to a consensus, and I will create a new 
> separate thread on those arguments, and hope to help others understand 
> why, while having cross purposes for security related issues that may 
> cross service boundaries, based on that it is an IMAP syntax proposal, 
> should at least be discussed, if not included.
>
> However, we did get some constructive ideas, and the 'id' idea is one 
> of those, and I intended to thread this topic separately.
>
> belong in the working group, see other thread for conversations on 
> that topic)
>
> (RFC2971)
> We did examine this, however RFC 2971 makes EXPLICIT arguments that 
> this information provided by ID is NOT to be used for any form of 
> 'flow control' ..
>
> chose an alternative so that we could explicitly allow for actions 
> based on the information provided.

There are valid concerns about not using client ID data in a way that 
reduces rather than increases interoperability, but the current text in 
RFC 2971 takes too heavy a hand.

> information across a non-secure layer.

At the time 2971 was written, TLS was expensive. Now we're in a 
situation where the cost of TLS is low compared to the potential 
reputation/privacy risks of not using TLS. I would support revising IMAP 
ID to explicitly disallow use of the command on a non-TLS channel (in 
case there are compatibility issues, I'd suggest: SHOULD NOT send / 
SHOULD NOT advertise unless TLS negotiated first).

On the flip side, I still prefer having a client-id solution that uses 
the same syntax and semantics across multiple protocols rather than a 
bunch of protocol-specific client-id solutions.

		- Chris

> distinct enough purposes that they should be considered as separate 
> need cases.
>
>> Well, originally I thought this wouldn't be the right place to 
>> discuss it, but since people are talking about it, here's what I sent 
>> to Deion Yu privately:
>>
>> send this command if it sees ID capability advertised. The servers 
>> can then either do something with it or ignore it.
>>
>>> We discussed draft-yu-imap-client-id in today's meeting, and while 
>>> we came to the conclusion that it wasn't a document for the working 
>>> the IETF could help with.
>>>
>>> pretty much it.  It's basically there are an input to the 
>>> calculation that every server has to make on every connection "how 
>>> much do I believe that this login is from who it says it's from", or 
>>> at a more meta level "how trustworthy is this connection and much do 
>>> I want to obey its requests".
>>>
>>> username and password (or whatever) gives the server sufficient 
>>> trust in the other end of the connection that it allows access to 
>>> (and maybe modification of a subset of resources, correlated by the 
>>> username used).
>>>
>>> help the authors find that area".
>>>
>>> Bron.
>>>
>>> --
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIF-g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=YN3qhDuB0d0fb0EX2hQldEeZLuL1WmHO1Y5wiwDgna0&e=
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIF-g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=YN3qhDuB0d0fb0EX2hQldEeZLuL1WmHO1Y5wiwDgna0&e=
>>
>
>
>
> -- 
> Visit us at 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linuxmagic.com&d=DwIF-g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=elczaDywCQFgqdljiyuhNG8UEh_GhuoW8O6uZHyx4NM&e= 
> @linuxmagic
> A Wizard IT Company - For More Info 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wizard.ca&d=DwIF-g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=jhObT8NWMpYCzCgqsKd5MEoWkWc0jKa3keqUZ-TZ_f0&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIF-g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=zhA2jiVBT1LOqIdrBzaD9nMZGHkzYaAUmR3ZC1aa64s&s=YN3qhDuB0d0fb0EX2hQldEeZLuL1WmHO1Y5wiwDgna0&e=

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 23 Jul 2018 13:38:18 -0400

According to RFC 2971 section 3.1: "This command is valid in any state."

Our server-side proxy already implements the ID command and replays it 
(so it can be logged on the backend).

The only barrier to using RFC 2971 (IMAP ID) protocol for the client-id 
function are some "MUST NOT" statements that would have to be revised. 
That's a better option than creating yet-another command that a 
server-side proxy has to replay to the backend and adding yet another 
round-trip.

		- Chris

On 21 Jul 2018, at 9:39, Bron Gondwana wrote:

>> discuss
>> can
>>> we
>>> calculation
>>> trust
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=axQ7rAtEYy7OhWHYKLDGlWzoKTgnGMydGUGDpd_Sz5A&s=Ib5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMFRAA2I&e=
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=axQ7rAtEYy7OhWHYKLDGlWzoKTgnGMydGUGDpd_Sz5A&s=Ib5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMFRAA2I&e=
>
> --

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=axQ7rAtEYy7OhWHYKLDGlWzoKTgnGMydGUGDpd_Sz5A&s=Ib5ngMIgWVP4VHtE1ebxRsGIIGy8lljdbjKbMFRAA2I&e=

---

From: Ned Freed <[email-masked]>
Date: Mon, 23 Jul 2018 15:29:27 -0700 (PDT)

> client certs in the TLS handshalke today with no protocol changes at

Keep in mind that the way client certificates work is that the server has to
request them with a Certificate Request message. The client then responds with
a Client Certificate message, which can be empty if the client has no
certificates to offer. It's then up to the server if it want to proceed
in the case where the client provides no certificates.

(This is for TLS 1.2. Other versions may differ but I really don't care
about trying to support any of this on old versions of TLS.)

> trust therefore it is bad."

Any mail server that supports AUTH EXTERNAL binding to a client certificate is
already doing this dance. And I'm dubious that servers that support this option
turn off the client certificate request when AUTH EXTERNAL is not enabled.
Additionally, I suspect that the code paths for this are reasonably well
debugged in the more popular SSL/TLS libraries most people use.

To put this another way, while there may be implementation issues, I don't
expect the changes necessary for a server to request such a certificate
to break existing clients. 

Of course this doesn't address the issue of getting clients deployed that
suport this, especially if part of this include a mechanism for
automatically loading clients with certifictes.

> submit authorization.

Sure.

> That doesn't necessarily conflict except that
> server can't tell them apart.

I can't speak to other servers, but the way ours maps certificates to user
identities is very flexible: It can require effectively an exact match with a
certificate stored in LDAP or it can just key off of  some identity field in
the certificate.

What we don't support is using a certificate to enable a subsequent
authentication step. The certificate either performs the authentication step
implicitly (which is then bound to the session by AUTH EXTERNAL) or it is
ignored.

>  That's probably not a problem until it

Which IMO needs to be automated. Of course there are multiple ways to do it:
The simplest being for the client to just generate a self-signed cert, send
it, and have the server cache it the first time.

Lots of options here, and lots of tradeoffs.

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 24 Jul 2018 13:18:58 +0300

On 23 Jul 2018, at 20.59, Chris Newman <[email-masked]> wrote:
> 
>> Also, the existing RFC does not address the issue of presenting that information across a non-secure layer.
> 
> At the time 2971 was written, TLS was expensive. Now we're in a situation where the cost of TLS is low compared to the potential reputation/privacy risks of not using TLS. I would support revising IMAP ID to explicitly disallow use of the command on a non-TLS channel (in case there are compatibility issues, I'd suggest: SHOULD NOT send / SHOULD NOT advertise unless TLS negotiated first).

Unfortunately capabilities can't really change after STARTTLS, since the tagged OK reply is done before the TLS handshake.

Anyway this brings to my mind: What if the client-id was sent as a TLS extension instead? It would then work with all protocols, regardless of what authentication is used. Of course, might be more difficult to get all the TLS libraries to be updated..

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jul 2018 06:59:10 -0700 (PDT)

> On 23 Jul 2018, at 20.59, Chris Newman <[email-masked]> wrote: > > >
information across a non-secure layer. > > 

> > At the time 2971 was written, TLS was expensive. Now we're in a situation
> > where the cost of TLS is low compared to the potential reputation/privacy
> > risks of not using TLS. I would support revising IMAP ID to explicitly
> > disallow use of the command on a non-TLS channel (in case there are
> > compatibility issues, I'd suggest: SHOULD NOT send /SHOULD NOT advertise
> > unless TLS negotiated first).

> Unfortunately capabilities can't really change after STARTTLS, since the
> tagged OK reply is done before the TLS handshake.

RFC 2595 section 2.1 says:

      Once TLS has been started, the client MUST discard cached
      information about server capabilities and SHOULD re-issue the
      CAPABILITY command.  This is necessary to protect against
      man-in-the-middle attacks which alter the capabilities list prior
      to STARTTLS.  The server MAY advertise different capabilities
      after STARTTLS.

Am I missing something here?

> Anyway this brings to my mind: What if the client-id was sent as a TLS
> extension instead? It would then work with all protocols, regardless of what
> authentication is used. Of course, might be more difficult to get all the TLS
> libraries to be updated..

I think you're going to have a great deal of difficulty explaining why
you need a new extension when (a) A client certificate seems to have
all the necessary properties and (b) If for some reason client certificates
cannot be used, the existing client authz extension probably can be.

More generally, while it is fine in theory to want to define new mechanisms to
do stuff, suc proposals need to be accompanied by substantive technical
analysus as to why existing capabilities are insufficient to the task.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2018 10:25:56 -0400

In article <[email-masked]> you write:
>Anyway this brings to my mind: What if the client-id was sent as a TLS extension instead? It would then
>work with all protocols, regardless of what authentication is used. Of course, might be more difficult to
>get all the TLS libraries to be updated..

How about if the client-id were sent in a self-signed client
certificate?  No changes needed to the libraries, just as Ned noted,
the server needs to set a flag in the SSL setup asking the client to
send it.

It could use the cert's serial number as the client-id.

R's,
John

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 24 Jul 2018 17:38:56 +0300

> Am I missing something here?

Oh right, I was mainly thinking from server's point of view that it can't push new capabilities unless client requests it. I wonder if all clients actually do that.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Jul 2018 15:42:22 +0100

> Oh right, I was mainly thinking from server's point of view that it can't push new capabilities unless client requests it. I wonder if all clients actually do that.
They should, as otherwise the might be unable to authenticate. (Some 
servers only advertise some SASL mechanisms after STARTTLS.)

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 24 Jul 2018 17:47:41 +0300

> It could use the cert's serial number as the client-id.

Some installations are using CA signed client certificates for authentication, which would prevent the client from adding client-id field to the cert. I guess this could still work for installations that aren't using such client certs, but seems a bit bad to exclude this kind of an additional security feature from installations that have gone through all the trouble of increasing their security by using client certs.

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 24 Jul 2018 08:14:08 -0700

> Some installations are using CA signed client certificates for authentication, which would prevent the client from adding client-id field to the cert. I guess this could still work for installation…

Which appears to suggest that using a VERB would have more universal 
appeal, and might be simpler to implement/adopt than using the TLS 
client-id field.  Albeit an interesting concept ..

Implementation of the 'CID' VERB could still pass the client-field in as 
a token and TYPE for the client-id, should an IMAP client developer 
chose to use this for their implementation.  Servers COULD validate the 
string passed in as a TLSCLIENTID 'TYPE' against the actual information 
presented in a TLS extension should they choose to.

---

From: "John R Levine" <[email-masked]>
Date: 24 Jul 2018 12:09:47 -0400

On Tue, 24 Jul 2018, Timo Sirainen wrote:
> Some installations are using CA signed client certificates for 
> authentication, which would prevent the client from adding client-id 
> field to the cert. I guess this could still work for installations that 
> aren't using such client certs, but seems a bit bad to exclude this kind 
> of an additional security feature from installations that have gone 
> through all the trouble of increasing their security by using client 
> certs.

Hey, I have an idea.  It could use the cert's serial number as the 
client-id.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jul 2018 08:53:42 -0700 (PDT)

> authentication, which would prevent the client from adding client-id field to
> the cert.

Actually, it can be one in at least two ways - the client-id could be added
to some field in the existing certificate, or the client certificate message
could simply include both certificates.

> I guess this could still work for installations that aren't using such client
> certs, but seems a bit bad to exclude this kind of an additional security
> feature from installations that have gone through all the trouble of increasing
> their security by using client certs.

As I explained previously, the mapping of client certificates to a user
identity has to be done regardless, nothing prevents a many-to-1
mapping from being implemented, and at least some implementations already
support it.

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 24 Jul 2018 19:29:05 +0300

On 24 Jul 2018, at 19.09, John R Levine <[email-masked]> wrote:
> Hey, I have an idea.  It could use the cert's serial number as the client-id.

I don't think it's really a client-id anymore if the user can simply copy their client certificate to another device. Which is what I'd expect to happen much more often than the user requesting a new certificate whenever they change a phone/laptop/etc.

---

From: "John R Levine" <[email-masked]>
Date: 24 Jul 2018 12:45:26 -0400

> I don't think it's really a client-id anymore if the user can simply copy their client certificate to another device. Which is what I'd expect to happen much more often than the user requesting a n…

How are you going to forbid that?  I can make my software send any cert or 
ID I want.  I'm sure I'm not the only person here who's extracted session 
cookies from a browser so I can use a site from wget.

Keeping in mind the threat model here, I think that having the ID say that 
this client is under the same control as a client you've talked to before 
is good enough.

Regfards,

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jul 2018 09:50:37 -0700 (PDT)

> > I don't think it's really a client-id anymore if the user can simply copy
> their client certificate to another device. Which is what I'd expect to happen
> much more often than the user requesting a new certificate whenever they change
> a phone/laptop/etc.

This is one of the reasons why the process of setting this up has to be
automated and done in the background, regardless of what the underlying
technology is. As I explained previously, the simplest way to do this with
certs is for the client to autogenerate a self-signed certificate on an
as-needed basis. 

> cookies from a browser so I can use a site from wget.

True, but there are less geeky examples. Once web sites started banning browers
on the basis of the ID they send it didn't take long for a crop of browser
extensions to appear to let you set the id to whatever value you like. The fact
that people use such things despite the fact that web servers actually do serve
up content in a browser-specific way, making these extensions more trouble than
they are worth, should say something about how well enforcement in cases where
there's no comparable downside is likely to work.

> this client is under the same control as a client you've talked to before

It's also all you can expect.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jul 2018 09:58:30 -0700 (PDT)

> > the cert. I guess this could still work for installations that aren't using
> > such client certs, but seems a bit bad to exclude this kind of an additional
> > security feature from installations that have gone through all the trouble of
> > increasing their security by using client certs.

I've already explained that this is not the case.

> client-id field.  Albeit an interesting concept ..

It's VERBs plural, not VERB. SUBMIT at an absolute minimum. In our case there
would be five new VERBs needed - IMAP4/POP3/SUBMIT/Managesieve/MTQP. All
separate code. All requiring testing.

And that's not even looking at the client side of things.

In contrast, either a SASL level or TLS level solution can be done
in common code.

> presented in a TLS extension should they choose to.

Absent a cogent technical argument explaining why it's OK to ignore SUBMIT,
to say nothing of the other email protocols, let's please stop claiming this
can be an IMAP-only thing.

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 24 Jul 2018 22:51:50 +0300

> certs is for the client to autogenerate a self-signed certificate on an

Sure, for self-signed certificates I agree this can be done easily and in various nice automated ways. I just don't see this same method working well for installations that require CA-signed certificates from clients.

>> cookies from a browser so I can use a site from wget.

Sure, but that's not a problem.. I suppose we should first define more precisely the purpose of this client-id feature. I'm assuming that the main use case it's intended to help with is:

 - user keeps logging in with user=foo password=bar client-id=1234 -> ok
 - user's password gets leaked to attackers (because the user uses the same password in many random web sites)
 - attacker attempts to login as user=foo password=bar client-id=3456 -> server will reject the login, maybe requiring further validation via some web page

The client-id should be such that it's not normally getting leaked along with the password. That also makes certificate serial numbers quite bad for this purpose, because they're easily guessed.

So as for CA-signed certs, the "client-id" would have to be determined at the time the certificate is created/signed. Doing this and transferring the certs to the client is already quite a lot of trouble. So when a lazy user gets a new phone, they'll just copy the old certs to the new phone and give the old phone away. Now both the old and the new phone has the same old valid user + password + client-id combination, so this client-id feature doesn't bring any benefits. Compared to if the client-id was sent some other way, the old and the new phone would have different client-ids, which could allow server to see that the user is using multiple clients, potentially blocking the old client-id or asking user to verify whether it's really intentional. The user could of course always fake the client-id with some special software to keep using the old client-id, but what's the point? Its purpose is to make the user's security better.

---

From: "John R Levine" <[email-masked]>
Date: 24 Jul 2018 16:20:30 -0400

I agree none of this is perfect, but I would prefer not to make the 
perfect the enemy of the better than we have now.

On Tue, 24 Jul 2018, Timo Sirainen wrote:
> Sure, for self-signed certificates I agree this can be done easily and 
> in various nice automated ways. I just don't see this same method 
> working well for installations that require CA-signed certificates from 
> clients.

True, but that is a self-inflicted wound.  This isn't likely to require a 
signed cert anywhere that doesn't already require it for other reasons.

> - attacker attempts to login as user=foo password=bar client-id=3456 -> server will reject the login, maybe requiring further validation via some web page

Sounds right.

> So as for CA-signed certs, the "client-id" would have to be determined 
> at the time the certificate is created/signed. Doing this and 
> transferring the certs to the client is already quite a lot of trouble. 
> So when a lazy user gets a new phone, they'll just copy the old certs
< to the new phone and give the old phone away.

Anyone who gives his phone away without wiping it is already in deeper 
trouble than we can fix.

> The client-id should be such that it's not normally getting leaked along 
> with the password. That also makes certificate serial numbers quite bad 
> for this purpose, because they're easily guessed.

It's all software.  No matter what form the client-id takes, sufficiently 
clever malware can steal it.  Stealing a cert might be marginally harder 
than stealing a string out of a table, certainly no easier.

One minor advantage of putting the client ID in a cert is that pretty much 
solves the problem of credentials being sent in the clear.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Thu, 26 Jul 2018 12:17:24 -0700 (PDT)

> Sure, for self-signed certificates I agree this can be done easily and in
> various nice automated ways. I just don't see this same method working well for
> installations that require CA-signed certificates from clients.

You'll have to be much more specific as to what the issues are going to be.
I'll note that nothing prevents an implementation from handling a CA-signed
certificate as a self-signed one, and only using the CA-signed aspect for
other purposes.

> Sure, but that's not a problem.. I suppose we should first define more
> precisely the purpose of this client-id feature. I'm assuming that the main use
> case it's intended to help with is:

>  - attacker attempts to login as user=foo password=bar client-id=3456 ->
>    server will reject the login, maybe requiring further validation via some web
>    page

I'm assuming more or less the same thing.

> The client-id should be such that it's not normally getting leaked along with
> the password. That also makes certificate serial numbers quite bad for this
> purpose, because they're easily guessed.

The first rule of using self-signed certificates is that in order to validate
them you have to store and compare the entire certificate or its cryptographic
equivalent, e.g., a hash. This is because by definition anyone can take the
same certificate content, sign it themselves, send you that instead, and in the
case of TLS use the private key they just generated to generate the client
verification message.

The fact that the verification is done with a signature means it's Mostly
Harmless for the entire certificate to leak.

Or, to put this another way, for the use-case you describe, the equivalent to
the client-id is the entire certificate including the signature, not the
serial number.

Having said that, there are other use cases for client-id, such as
communicating the type of client, that could be accomplished by putting some
kind of additional identifier in the certificate, possibly in the serial number
field - although since this is an integer it doesn't seem like the most
friendly way to do it.

But regardless of the field involved, I'm opposed to doing this sort of thing,
for three reasons. I've already explained my main objection in previous
messages: I think having client type information as part of this is an
invitation to bad behavior.

The second is that the client certificate is exposed in the clear in TLS 1.2.
As such, I think putting information about the client in the certificate is
a bad idea. (This is fixed in TLS 1.3, but that's a dependency we don't need.)

The third is that unlike the use-case you describe, these other use-cases
seem to be much more protocol-specific. And in the case of IMAP, we already
have an extension to send a client-id for these purposes.

> So as for CA-signed certs, the "client-id" would have to be determined at the
> time the certificate is created/signed. Doing this and transferring the certs
> to the client is already quite a lot of trouble.

With all due respect, this statement indicates that you're seriously out of
date in regards to getting certs signed. ACME has completely changed the
landscape in this regard.

> So when a lazy user gets a new phone, they'll just copy the old certs to the
> new phone and give the old phone away.

First, most users wouldn't have a clue as to how to do this. Second, this
assumes there's a way to get the certificates and private keys out of the
phone, and there's no reason to allow that. Third, there should be no need to
do this since, again, the process should be automatic, irrespective of whether
it's a self-signed or CA-signed cert.

> Now both the old and the new phone has the same old valid user + password +
> client-id combination, so this client-id feature doesn't bring any benefits.

This would require a massive implementation botch along multiple axes. Not
likely.

				Ned

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 26 Jul 2018 16:46:55 -0700

On 18-07-26 10:13 AM, Ned Freed wrote:

>> AS well, this
>> working group currently is IMAP centric.
> 
> Which is one of the reasons why the conclusion at the IETF meeting was 
> that no
> work on this will be done in this WG. Rather, this is simply a useful 
> place to
> have a discussion about possible solutions in this space.

I might point out, that the conclusion was to discuss whether it SHOULD 
be discussed in this WG, and that discussion is still to reach a 
conclusion about whether it should be herein..

....

> 
>> IMHO the VERB method allows for a greater flexibility, but again.. that
>> should be discussed on a different thread.
> 
> That's a technical claim. Care to back it up with some analysis?
> 
>                  Ned

Yes, correct.. and that is probably what we should focus on..

* The RFC2971 (ID) is an excellent example for something that 'could' be 
useful across protocols, and yet was considered within the IMAP group singly

* The proposed CID (Let's start calling it CLIENTID, based on previous 
feedback, pending a consensus for a VERB name) is very easy to 
implement, both in the client side and server side, and is useful for 
other 'value propositions'.  While using it in 'collateral' information 
for authentication is ONE of the uses we envision for it, the CLIENTID 
information can also be valuable in other ways, for instance..

* those of us doing 'abuse' detection.. Based on CLIENTID being 
presented, and how it is presented, could be helpful additional information.

* Specialized IMAP servers with custom implementations for a specific 
customer set, might be able to reject connections based on whether the 
CLIENTID TYPE presented is the TYPE of client they permit/support

* Administrators, Domain Users, or end customers can specify advanced
   rule decisions, based on CLIENTID.. eg only allow connections from 
the   TYPE of IMAP clients I use..

* Enforcement of specific SASL's for a given class of devices
   (Also good for testing, eg if CLIENTID TYPE = 'X-TEST', use a
   different SASL mechanism, or PLAIN TEXT only allowed for certain
   CLIENTID TYPES. Or to let the IMAP mechanism have conditional support
   based on a unique CLIENTID token.. in a shared IMAP environment.

* Standardized alerting tools based on CLIENTID TYPE or TOKEN

* Different Logging Mechanism's based on a CLIENTID TYPE or TOKEN

* IMAP concurrency based on CLIENTID token

* IMAP timeouts based on CLIENTID TYPE

* Statistical analysis based on CLIENTID TYPE or TOKEN

* Ability for IMAP for custom/legacy SASL or authentication layers that 
it is difficult to update/upgrade who might only return True/False answers

* Permission choices based on CLIENTID to use certain 3rd party 
authentication methods in custom/proprietary IMAP scenarios

* Requires updates to less SASL implementations

* Authentication offloading/load balancing scenarios

* Easier for IMAP client vendors to implement, vs modifying existing
   SASL implementations

* Easier to implement standardized error conditions, vs different SASL
   mechanisms responsible for error conditions.

* Easier for IMAP clients to recognize and respond to error conditions

* Reduce load on authentication systems

* Allow IMAP clients to alter behavior based on CLIENTID SUPPORTED
   advertisement in the IMAP handshake

Sorry, but I can go on for quite a while about the possibilities of 
CLIENTID as a standard in IMAP, and it doesnt' take long when evaluating 
the various IMAP server implementations in the wild.. Let alone the IMAP 
clients, that to gain the same value presented in a SASL alone, to see 
how incremental adoption will be easier as part of the IMAP protocol 
itself..

And of course, in many implementations the IMAP service itself may have 
access to different resources that the internal or remote SASL 
processors may not have access to.. in order to compare the CLIENTID 
information to other mechanisms not related to authentication.

And finally, the more distinct we keep the CLIENTID mechanism, from any 
authentication mechanism, the less likely that a compromise of one 
mechanism or the other, will result in a complete compromise of 
information needed to access IMAP resources..

How about we start with these ideas, and see if a discussion of these 
helps confirm that the best place to implement, is as an IMAP verb.

*