Ben wrote:
> Lutz Jaenicke wrote:
> >
> > On Mon, Nov 27, 2000 at 04:11:31PM -0500, Jeffrey Altman wrote:
> > > The way I see it, the KRB5 ciphers need to be filtered out at the
> > > location where the Client Hello message is both constructed in the
> > > client and processed in the server. That is why I am looking at the
> > > translation functions. If KRB5 can't possibly succeed, don't offer
> > > them to the server or ignore them on the server.
> >
> > I am not sure whether I missed something. The list of ciphers available
> > (that is: offered by the client and/or accepted by the server) is set
> > with SSL_CTX_set_cipher_list() (or SSL_set_cipher_list(), respectively).
> > Only the ciphers allowed there are offered from the client to the server;
> > the server will only pick a cipher if it was set using these functions.
> > Actually, the useable list is even more restricted, a DSA cipher will
> > only be chosen, if the server has a DSA certificate, ciphers with DH
> > (this includes DSA ciphers) will only be chosen, if DH parameters are set...
> >
> > What OpenSSL does not offer is a server-side "cipher choice" callback.
> > The client sends a list of ciphers and an openssl server will always choose
> > the first of the ciphers it does support.
>
> The point is that he wants to vary the list according to whether the
> client presented a cert or not. Hadn't really thought about a cipher
> choice callback, but actually that might be a cool way to address the
> problem.
Given the direction this thread has taken I think I need to explain
something about Kerberos 5 which I just assumed was a known fact.
Kerberos 5 is not a public key algorithm. It is a symetric key
algorithm. Therefore, both the client and the server must both have
their respective credentials before the protocol negotiations begin,
otherwise, failure is guarranteed.
In the case of the client, the end user must have retrieved from the
Kerberos 5 KDC a Ticket Granting Ticket. If there is no TGT or if the
TGT has expired we can removed KRB5 from the list of ciphers that the
client side TLS sends to the server in the Client Hello message. It
would be pointless to send KRB5 ciphers to the TLS server because if
the TLS server were to choose one, its use would fail.
Assuming that the client has a TGT, when the client wants to
communicate to a service (the TLS server) it must retrieve a Service
Ticket for the service. This service ticket is what will be sent from
the client to the server to exchange the shared secret (the Kerberos
session key). However, this service ticket is encrypted in the
service's key. In order for the service to be able to decrypt this
ticket and get the session key it must know its own key. This key is
stored in a keytab file (or database, ....).
If there are no keys stored on the server it is certain that the TLS
negotiation will fail if a KRB5 cipher suite is chosen. Therefore, if
there are no keys the TLS server should skip over all requests by the
client to use a KRB5 cipher.
Both of the tests that need to be done to perform this filtering can
easily be implemented without callbacks to the application. In fact,
calling the application would serve no purpose since the application
may be completely unaware of the existence of Kerberos. Kerberos if
properly configured can be used with TLS without knowledge of the
application.
The only question that I have is where in the process of constructing
the ClientHello message should the client filter out KRB5 ciphers; and
where in the processing of the ClientHello message should the server
ignore KRB5 ciphers.
My guess at the moment is that the easist place is in the functions
that convert stacks of ciphers to/from byte streams of ciphers since
those functions must be called in all of the appropriate places.
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
