[5663] in Kerberos
SSL as Kerb replacement
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Thu Aug 10 20:57:50 1995
From: "Donald T. Davis" <don@cam.ov.com>
Date: Thu, 10 Aug 1995 10:49:53 -0400
To: bkelley@cat.cup.hp.com
Cc: kerberos@MIT.EDU
bob kelley wrote:
>> * it's vulnerable to a man-in-the-middle attack, because
>> there is no way for the user to authenticate his top-
>> level certification authority keys.
>>
> I don't think man-in-the-middle attack can happen.
> The latest v3 SSL rfc draft by Taher El-Gamal (of
> El-Gamal and DSS fame) provides an analysis of why
> the man-in-the-middle attack doesn't work against SSL.
> See
> ftp://ietf.cnri.reston.va.us/internet-drafts/draft-hickman-netscape-ssl-01.txt
here's the analysis bob cites. it does not address the fact
that ssl users and clients cannot verify the authenticity of
the top-level certification authorities' public keys. indeed,
the ssl spec that bob cites explicitly states that ca authentication
is outside ssl's scope. (see below).
> Hickman, Elgamal [page 27]
>
> D.4 The Man In The Middle
>
> The man in the middle attack works by having three people in a
> communications session: the client, the server, and the bad guy. The bad
> guy sits between the client and the server on the network and intercepts
> traffic that the client sends to the server, and traffic that the server
> sends to the client.
>
> The man in the middle operates by pretending to be the real server to the
> client. With SSL this attack is impossible because of the usage of server
> certificates. During the security connection handshake the server is
> required to provide a certificate that is signed by a certificate authority.
> Contained in the certificate is the server's public key as well as its name
> and the name of the certificate issuer. The client verifies the certificate
> by first checking the signature and then verifying that the name of the
> issuer is somebody that the client trusts.
>
> In addition, the server must encrypt something with the private key that
> goes with the public key mentioned in the certificate. This in essence is a
> single pass "challenge response" mechanism. Only a server that has both
> the certificate and the private key can respond properly to the challenge.
>
> If the man in the middle provides a phony certificate, then the signature
> check will fail. If the certificate provided by the bad guy is legitimate,
> but for the bad guy instead of for the real server, then the signature will
> pass but the name check will fail (note that the man in the middle cannot
> forge certificates without discovering a certificate authority's private key).
>
> Finally, if the bad guy provides the real server's certificate then the
> signature check will pass and the name check will pass. However, because
> the bad guy does not have the real server's private key, the bad guy cannot
> properly encode the response to the challenge code, and this check will
> fail.
>
> In the unlikely case that a bad guy happens to guess the response code to
> the challenge, the bad guy still cannot decrypt the session key and
> therefore cannot examine the encrypted data.
here's the part of the ssl spec that discusses ca-authentication.
here, "issuer" means, "certificate issuer," aka certification
authority.
> The issuer name must resolve to a name that is deemed acceptable by
> the application using SSL. How the application using SSL does this is
> outside the scope of this memo.
>
> Certificates are validated using a few straightforward steps. First, the
> signature on the certificate is checked and if invalid, the certificate is
> invalid (either a transmission error or an attempted forgery occurred).
> Next, the CertificateInfo::issuer field is verified to be an issuer that the
> application trusts (using an unspecified mechanism).
the ssl spec assumes that ca-authentication is somehow taken
care of by the x.509 infrastructure, but it is not. it is
the user's responsibility to manually verify and securely
maintain the authenticity of his top-level ca public keys.
on this slender thread, the security of all public-key
cryptography depends. somehow, i can't resist the temptation
to pick at that thread.
-don davis, boston
