Re: "Onion model" explained

Joe, I know we've tracked way off topic into these minutia, but I'll
"respond" to your "challenge" for the sake of completeness.  ;)

Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Fri, Jul 12, 2002 at 10:32:33AM -0700:
> [snip]
> > > Say, if you buy stuff from an
> > > https website, do you chllenge the sellers?  I bet you don't,
> > > even though it's your money that's at stake. 
> > 
> > I trust that my SSL/TLS-enabled browser challenges the seller's web
> > server.
> 
> I'm interested in knowing which brand of browsers uses
> challenge/response to verify ownership of private keys
> (of signed certs).

In TLS, the premaster secret serves as the "challenge" (though not
exclusively for this purpose), and a correct MAC of a subsequent
record is the "response".  You have filled in some of the details I
omitted from my abbreviated description below; the conclusion is that
the TLS protocol terminates with a bad_record_mac error if any keyed
MAC is not correct.  A correct MAC proves that the key agreement
process was successful, which could only have occurred through
the server's application of the correct private key.

> > It encrypts the pre-master secret using the (supposed)
> > server's certificate.  If the server is unable to decrypt it,

[...here is where I left out some steps...]

> > that proves it likely to be unauthentic, and the protocol
> > terminates.
> 
> In SSL/TLS, the pre-master secret (PMS) is not meant for the
> purpose of challenge/response; and doesn't serve such purpose.
> The PMS is for deriving the master secret (MS, which will then be
> used for generating the symmetric keys (for the TLS session)).

... and for generating the MAC secrets.  Thus, if the client and
server cannot both arrive at the same set of secrets (because server
could not decrypt premaster secret, because server is not the
authentic holder of the correct private key...) the result will be a
MAC failure.

> During a TLS handshake, your browser (ala TLS client), after
> verifying the cert from the TLS server (contained in the
> handshake:ServerHello message), encrypts it with the TLS
> server's public key and sends it to the TLS server.
> The authN proof -- proof is not the most desirable
> word I would use here, but I use it anyway for the
> sake of corresponding with your text -- lies in the MAC
> of all handshake messages, starting from handshake:ClientHello,
> up to and including the handshake:Finished!  In short, the
> coup de grace authN is in the MAC, not in the encrypted PMS.

Sure; but failure to decrypt the premaster secret causes MAC failure,
so there is a direct relationship between them.  We are saying the
same thing.  (Minor correction: there is no MAC for the first few
handshake messages.  It is not possible to key the MAC until the MAC
secrets have been established, which requires the ClientKeyExchange
message.)

--Pete
Pete Wenzel <pete@seebeyond.com>
SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

Received on Friday, 12 July 2002 16:08:59 UTC