Subject: Re: [Extra] client-id next steps - client-id vs existing id (RFC2971)

From: Michael <[email-masked]>
Date: Thu, 26 Jul 2018 15:39:27 -0700

Yes, while a 'nifty' concept as pointed out when Timo  first brought this up..

(And Ned's arguments back up)

We have to think in terms of incremental adoption.

And consider especially the client end; there are lot more client softwares that need updating than server implementations.
Many 'client' softwares simply are abstracted from the TLS layer, this would be a lot harder to implement for them, and make adoption a harder sell.. And to expect 'users' to do this would be unrealistic.

Consider standard clients over SSL, they simply use the OS to open the socket.. 
How would the opportunity present itself 
Also consider shared environments.. 
Also consider other 'secured channels' ..

Sorry Timo, I think another approach will have to be considered...
Back to considering expanding ID or using CLIENTID ;)
(Of course, an email client can still decide to use CLIENTID PRIVCERT  if that suits their purpose of what a client id should be)

On Thu, 26 Jul 2018 12:17:24 -0700 (PDT)
Ned Freed  wrote:
>> On 24 Jul 2018, at 19.50, Ned Freed  wrote:
>> >
>> >> On Tue, 24 Jul 2018, Timo Sirainen 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.
>> >
>> > 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.
> 
>> 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.
> 
>> >> 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.
> 
>> 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
> 
> 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
> 
> _______________________________________________
> Extra mailing list
> [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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada