[chef] Re: Re: Re: Re: New Authentication in Chef 0.8

[Miguel Cabeça < >]

Guys,

> The difference here is problem domain, applicability to the task, and
> security profile.  What we are doing is digitally signing the
> *payload* and *shape* of each request - confirming that it was, in
> fact, authored by someone in control of the given client key.  This is
> different from (but uses a similar mechanism to) SSL/TLS, but it's
> happening at a different layer.  SSL/TLS says that, on the protocol
> level, you have secure channel between two sides (who may or may not
> mutually authenticate one another.)  That's great, and you should do
> that.

I fully understand this. When you say you are signing the request (payload 
and shape) you are in fact authenticating the source of the request.
When you establish a TLS connection with client certificates you are creating 
an encrypted AND authenticated channel. Everything that traverses that 
channel can be assumed to be an authenticated payload.
So, in both cases you have authentication of the payload, albeit on different 
levels (transport level vs application level)


> The new authentication mechanism within Chef is saying that, at the
> application level, we are certain that the request *as drafted and
> signed by the origin* is the request that we receive on the other
> side.  We are digitally signing the content and shape of each request,
> giving us another layer of useful security - against things like
> replay attacks, etc.

What for? If you already have an authenticated TLS connection, signing the 
payload inside that channel gives you nothing more but complexity and 
overhead. Everything is taken care of by the security layer, 
man-in-the-middle attacks, replay attacks, etc. If you do not have an 
authenticated TLS connection, signing the payload gives you the necessary 
authentication of the client, and you have to implement additional 
protections against the more common attacks.

> We're not re-inventing the wheel - we're simply saying that there are
> two layers of security here: transport layer security and application
> layer security.  Chef provides for the application layer security, and
> for most people, SSL/TLS handles transport layer security.

What I'm trying to say here is that using payload signing INSIDE an 
authenticated  TLS channel gives you nothing additionally in terms of 
authentication. The TLS channel can give you encryption, but can also give 
you optional authentication. 
This last feature of TLS could have been used. Instead you are suggesting the 
use of the encryption feature of TLS (ignoring the authentication feature) 
and implementing authentication yourself of the payload. Am I making any 
sense?


> If what we did was to use SSL certificates as our authentication
> layer, it assumes that all traffic *must* be traversing SSL.  Our
> answer is that all traffic must be digitally signed with a trusted
> private key - and it may *also* traverse an encrypted (and perhaps
> authenticated) transport layer.  Imagine wrapping Chef requests in a
> new protocol (like AMQP) and you'll start to see the idea - as long as
> the request is signed, we can authenticate it at the application
> level.

Or you could use TLS to protect AMQP[1], or use TLS to protect SMTP, or use 
TLS to protect any other protocol you choose besides HTTP to transmit Chef 
requests.

> Most importantly, the chef authentication mechanism identifies the
> originator of the api call by its client ID and allows chef to
> determine the level of client privileges allowed. If the client ID
> isn't registered in couchdb and known to the chef-server, then the api
> request is rejected.


Using a client certificate with TLS the client could be identified by the CN 
of that certificate, like any browser that verifies the CN of the certificate 
presented by the server to match the hostname being accessed. It's the same 
process.

Don't get me wrong on this, I'll use this authentication method when 0.8 is 
released, but I think It was an unnecessary development effort.

Just my 2¢

Best Regards

Miguel Cabeça

[1] http://www.amqp.org/confluence/display/AMQP/AMQP1.0+SIG