I understand that Kerberos is used as an authentication protocol. However, would it be possible to achieve a similar effect as Diffie-Hellman with Kerberos i.e. establish a session key which can be used for further encryption of data to be transmitted, once authentication has been performed?
Kerberos is designed to be a pure authentication protocol. It actually builds a session ticket to proof your identity to the the server, it's not an encryption protocol (like SSL for instance).
Yes, with some caveats. As a prior answer described, Kerberos authentication also shares a session key between the client and server principals, which they can use for further communication. Another prior answer claimed that “Kerberos is not an encryption protocol,” but this is not true: the protocol includes messages specifically for sending arbitrary data protected by the session key negotiated during authentication (KRB_SAFE and KRB_PRIV). The most common way to take advantage of this is via GSSAPI (which is the most common way to use Kerberos at all, rather than via a Kerberos-specific API like that of MIT Kerberos or Heimdal). After creating a GSSAPI security context, the peers can use the routines
gss_unwrap() to seal data for transmission, either with just integrity checking, or integrity and confidentiality (encryption). Probably the most common example of this actually being used is via SASL, when the client requests installation of a “security layer” after authentication with the GSSAPI/Kerberos mechanism.
Keep in mind, though, that unlike Diffie-Hellman you don’t have forward secrecy here. In the simplest case the KDC generates the session key, so it was always known to a party other than the communicating peers. The key may actually be a “subkey” generated by one of the peers, which is better, but still it’s generated by one side only, making it vulnerable to one-sided Trojan or Byzantine attacks, whereas Diffie-Hellman limits either side’s ability to control the final shared key. And in either case the session key is ultimately secured on the wire by the long-term key of the server, which is typically in a keytab file on the server as well as in the KDC, and prior recorded communications will be compromised if that is later revealed.
While not commonly used for the purpose, it can. As a side effect of mutual authentication, Kerberos principals share a cryptographically strong session key, that can be used to achieve confidentiality.
Kerberos contains primitives to exchange encrypted (and authenticated) data between principals. They are exposed to an application as krb5_mk_priv() and krb5_rd_priv() calls.
These functions are available in both MIT and Heimdal implementations, at least on Linux and BSD-based systems. I do not think Windows expose these function though.