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

[Adam Jacob < >]

On Wed, Feb 10, 2010 at 1:59 PM, Miguel Cabeça 
<
 >
 wrote:
> That's precisely what presenting a client certificate does in establishing 
> an SSL connection. Part of the SSL handshaking involves the client signing 
> something with his private key for the other side to verify with the client 
> public key (present in the certificate offered to the other side). After 
> the handshake, the secure channel guarantees that both sides of the 
> communication are authenticated to each other. The request could be sent 
> without further signing or any other special requirements.
>
> It seems to me that you've implemented something already offered for free 
> with the traditional SSL handshake. And the validation key is a 
> substitution of the CA-siging-the-certificate-to-be-presented-by-the-client 
> stuff.
>
> What am I seeing wrong here?

dreamcat four does a fine job in his reply, but I'm going to reiterate it.

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.

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.

Additionally, this mechanism can be re-used outside of the transport
layer: if you want to authenticate a different kind of payload, that's
easily possible here.

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.

So rather than thinking about this as "rebuilding ssl", it's actually
"implementing per-request digital signatures".

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.

It's not 'this or SSL', it's 'this and SSL'.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: