I understand how mutual authentication works between a client and a server, however I am unsure how I would be able to get mutual authentication between two clients A and B?
"Client" and "Server" are just formal names for roles in situations where there is a natural asymmetry. Namely, one talks first: that's the "client".
This is how it goes in SSL: the protocol is defined to operate on a bidirectional transport medium. One of the entities talks first and sends a ClientHello message. There is no absolute requirement that the notion of "client" and "server" that SSL uses matches the notions of "client" and "server" for the underlying connection when that connection is a TCP socket over the Internet. It just happens to be that way.
In all generality, any authentication protocol between two systems (let's call them "A" and "B") works by sending messages to each other, and one of the systems will be the first to talk. As long as both A and B know who is supposed to talk first, through some convention, then the protocol will work. The convention is easy to obtain when there is an asymmetry, e.g. the software on one machine is not the same as the software on the other. For instance, for the Web, one system uses a Web browser (e.g. Firefox) while the other uses a Web server (e.g. Apache), and standards define what either is supposed to do.
Just imagine a phone call. Someone dials the number of the other. Normal behaviour is that the person who receives the call will talk first (and say "hello"). That's exactly the concept you want. If these two talking person want to run some authentication protocol, they will have to agree on their respective roles (they can call themselves "client" and "server" if that's their wish). Using the dialer/receiver asymmetry is a natural way to bootstrap that convention. But they could use just any other convention; for instance, they could use the lexicographic order of their names (Alice is the "client" and Bob the "server" because 'A' is before 'B' in the alphabet); or their birth date; or they may try randomly; or whatever.
That being said, in the specific case of SSL, there normally are certificates and the machine with the "server" role shows a certificate to the "client"; the "client" may also show a certificate to the "server". Certificates prove bindings between keys and identities, but this has any value only if the identity has some meaning. I.e., when the server shows its certificate to the client, the important point is that the server's certificate contains the server name, and the client expects a very specific server name (the one from the URL). Similarly, when the client shows its certificate to the server, this makes some useful authentication only if the server can find in the certificate some notion of identity which makes sense for him.
A more interesting situation with SSL is SRP: with this variant, no certificate at all. Client and server authenticate each other relatively to their knowledge of a shared secret (a password). They still must agree on who talks first ! And there is an extra point, which is the entity with the "server" role does not need to store the password itself, only a hashed version thereof (with some algebraic structure). In that sense, who assumes the "server" role is not completely arbitrary with regards to security: even in a mutual authentication protocol, security characteristics achieved on both sides may differ.
The simplest way is for each party to encrypt their communication with their private key. If you can decrypt my message with my public key, then I must have encrypted it. Of course that relies on you having a copy of my public key that you trust to have come from me. If we need ongoing secure, authenticated communication, then the first message is a key half. I encrypt a key half with your public key and you encrypt a key half with my public key - we exchange the encrypted key halves and combine the keys to create a session key, then use symmetric key crypto to maintain the security.
There are too many unknowns in your question. Do Alice & Bob have an out of channel communication? Do they know each other, is this their first transaction? How secure does the authentication need to be? How resilient?
Research Diffie-Hellman Key exchange or Internet Key Exchange Protocol, or Key Agreement protocol. These are all closely related to the problem you suggest.
You can also attempt transitive trust - this is the old pgp style where if my key is vouched for by enough people, then it is very likely that I'm me.
Everything that the great bear says is also true.
But I want to caution you - 90% of the error of any cryptosystem is not the protocol, it is the implementation. Just because someone has implemented an adequately secure SSL/TLS doesn't mean that yours is going to be.
