EAP-TLS is "just" plain SSL/TLS forced into the EAP format. EAP is an "authentication framework": a generic protocol for exchanging messages between two parties, in a question-response dialogue (the parties are usually designated as "client" and "server", whether this maps to the corresponding network concepts or not). TLS is nominally performed over a bidirectional channel for arbitrary bytes, both parties being able to talk simultaneously; however, the TLS "handshake", in which the tricky crypto occurs, is synchronous: at any point, only one party (client or server) talks, and both know who is supposed to speak next. Therefore, it is possible to split the TLS records into big packets which will be wrapped into EAP messages; that's exactly what EAP-TLS is about.
EAP-TLS achieves client authentication "by itself" when TLS certificate-based client authentication is employed: the client owns an asymmetric private key, and the corresponding public key is wrapped in an X.509 certificate, which the client shows to the server when the server asks for it. This kind of authentication works only when the client indeed contains a private key and can use it, so that's for devices, not humans (even if considering smart cards, the authentication will convince the server that the smart card is at the other end, and the server merely infers the involvement of the human owner of the smart card, under the assumption that the smart card would not do anything without the PIN code that only the human owner knows -- but the server does not see that PIN code and cannot be sure that it even exists at all).
So no biometrics for plain EAP-TLS. However, there is another mode of EAP-TLS in which no client certificate is requested; but then, EAP-TLS is just a transport mechanism, for another authentication mechanism which will be played within the TLS tunnel. In that case, EAP-TLS is just an additional network layer (a good one, since it allows for safely sending plaintext passwords, but a layer nonetheless). Note that PEAP is just the reverse: EAP inside a TLS tunnel. EAP-TLS-for-transport and PEAP are functionally similar, but correspond to distinct contexts (PEAP is there to get EAP messages when the context is a bidirectional tunnel for bytes; EAP-TLS is there to get a bidirectional tunnel for bytes when the context is a transport mechanism for EAP messages).
Speaking of biometrics, one must remember that this is about measuring things on a human body, not about secret data. Your fingerprints are not secret; you leave them just about everywhere and they can be recovered by low-tech attackers. The value in fingerprints is that nobody can have the same as yours attached to their fingers. This provides authentication, but only insofar as there is some mechanism which ensures that a real finger is placed on a real scanner. Otherwise, an attacker could just send a synthetic data packet over the network, claiming to be from a scanner, and containing a picture of your finger. The same applies to face recognition. Simply put, biometrics work well only in the presence of an armed guard (the guard does not perform the authentication, but makes sure that only true biological fingers/faces/eyes are put in front of the detector).
So what does this mean for your situation ? Mostly that EAP-TLS, PEAP... are not the relevant point. What you want is to authenticate both human users and machines, and you will need two distinct authentication methods.
For humans, you will need to map on that which works on humans, mostly passwords and biometrics. As explained above, biometrics really work only in restrictive contexts (many people use them in other contexts, but all they get is a warm feeling of security, not actual security). So this brings us back to passwords. Or you could say that humans are actually devices, with the smart card arrangement, or something similar (like a car key with the "unlock" button): the authentication is really for a device, that is assumed to be under exclusive control of a specific human user.
For machines, authentication can use a "machine password" (it is like a normal password, except that a machine will have no problem remembering a 25-letter sequence of random characters, so that's substantially easier than passwords for humans). Or it can rely on asymmetric cryptography (private key and certificate, see above).
Either way, you will probably want to know sufficiently early whether the client is a human or a device, so that the appropriate authentication mechanism may be used. And there is something just for that in EAP: the initial message from the server will be of type
Identity, and can be described as the question: "halt ! who goes there ?". It is then up to you to give "names" to both human users and devices, so that the server can quickly determine whether the client is a human or a device, e.g. based on the name format. The server, in EAP, is free to select the actual authentication method after having seen the
Identity Response from the client.