Random thoughts/crazy idea: Drop SSL certs

[Pierre-Yves Chibon]

On Mon, Apr 27, 2015 at 04:32:17PM +0200, Till Maas wrote:
> On Mon, Apr 27, 2015 at 03:45:00PM +0200, Pierre-Yves Chibon wrote:
> > Good morning everyone,
> > 
> > This week-end I had a random thought, which I quickly discussed with Dennis on
> > IRC on Sunday but that I thought might be interesting to discuss in a wider
> > audience.
> > 
> > The initial thought came from a text that Dennis wrote:
> > """
> > Releng tracks this data in 2 systems, 1 of which we own: Koji and Bodhi. Koji
> > uses ssl certs tied to FAS and bodhi uses FAS for authentication to provide a
> > strong relationship between a user and the content
> > """
> > Source: https://fedoraproject.org/wiki/ReleaseEngineering/Philosophy#Auditable
> > 
> > This has lead me to the question: Is this all what SSL certs are bringing us?
> > 
> > The following only works under the assumption that it is.
> > So SSL certs are basically a certain type of API token. Everyone has one,
> > specific to koji and the lookaside cache, time limited and gives us a way of
> > doing authentication and authorization server side.
> > 
> > So on this they behave just like any other API token, but using SSL certs has
> > some pros and downs:
> > 
> > pros:
> >   - Easy to find out when the token expires
> >   - In place and working
> >   - Known to the current process maintainers
> >  
> > cons:
> >   - One per client
> >   - Hard to invalidate iiuc (ie: if someone's machine is compromised/lost it is
> >     hard to make this user's certificate invalide)
> >   - Relise on the SSL pile
> >     - master certificate
> >     - self-signed vs signed by an authority
> >     - complex tooling
> >   - Makes us maintain a whole infrastructure stack around this (cf the dogtag
> >     discussion)
> >   - Relies on the master certificate that expires every X years making everyone
> >     generate a new client certificate
> > 
> > On the otherside, recently we have been more and more feeling the need for a
> > centralized API authentication place. Something along the line of a personalized
> > 0Auth. This has also pros and cons.
> > 
> > pros
> >   - API token per user and per application
> >   - Could support multiple tokens per application
> >   - Central place to manage API token (ie a central place to revoke someone's
> >     access if a machine gets compromised/lost)
> >   - Simpler than dealing with the SSL stack
> >   - Can be re-used by multiple applications
> > 
> > cons:
> >   - It's an idea and it needs work :)
> >   - Impacts
> >     - dist-git
> >     - koji
> >     - ?
> > 
> > I do realize that this would be a pretty big task to undertake but we are
> > currently at a stage where we are planning for the future, including for the
> > next generation of koji but also FAS3, dogtag, our master cert expiring in a
> > couple of years...
> > 
> > So I thought I would leave this here as food for thoughts and I'm happy to
> > discuss pros and cons of this idea.
> > 
> - not transfered in the clear unlike a token

What is ? :)
All our apps are running behing https and if API tokens are something not to do
I'd really like to know what are the recommended way of doing CLI authentication
that can last longer than a web-cookie/browser time-out.


Pierre