Context
It was our intention to build a secure network, with single sign-on mechanisms. With ‘secure’ we mean secure authentication and transmission of data. Kerberos solves the problem of secure authentication using a shared secret key architecture. In fact, while authenticating principals passwords are never sent over the cables. Authentication is based upon the ability of the principal of decrypting some piece of information.
Kerberos also solves the problem of mutual authentication: each service (server) and consumer must know for sure that they are communicating with authorized parties and not with fakes. This is cleverly solved using the Needham-Schroeder scheme. This algorithm enables two parties to share a session key, securely. The session key can be further used to protect communications between them. In particular, Kerberos introduces the concept of Authenticators. These are, basically, principal identifiers and timestamps. When a client initiates communication with a service, sends him … well it sends him a butload of things
but the important thing is that it sends him a Authenticator encrypted with the session key that both will use. However, the service cannot decrypt it yet, because it has no access to the session key itself. To obtain the session key, he first has to decrypt another part of the message sent by the client, which is the session key encrypted with the key that only he and the Ticket Granting Service share. Now, the service is prepared to decrypt the Authenticator sent by the client and reply to him with a new Authenticator which now contains the original timestamp plus 1. This goes, once again, encrypted using the same session key. This can somewhat be seen in the pictures below. They were taken from the course I’ve attended last year on Computer Systems Security.

Authentication protocol used in Kerberos. Simplified. Taken from the lecture notes of Computer Systems Security: http://web.fe.up.pt/~jmcruz/ssi/acetat/4-autentica.pdf

Service request phase. Simplified. Taken from the lecture notes of Computer Systems Security: http://web.fe.up.pt/~jmcruz/ssi/acetat/4-autentica.pdf
Wrapping up, mutual authentication is achieved, from the service side, by matching the information found in the Authenticator against the information found in the ticket (crafted by the TGS) and the network information. If everything matches, the client is authenticated. The client authenticates the server when it receives from it the proper authenticator in reply to its own.
Problem
By now we have authentication and, as a sub-product of kerberos system, communication encryption. OpenAFS can now enter here as a means to distribute, for example, the home directories of users over the network (network login facilities…). OpenAFS has the advantage of being a natively kerberized application. The problem is the type of encryption supported by it.
If I’m not mistaken, AES is accepted as the strongest encryption algorithm and is also supported by Kerberos. However, by what I know, there are two problems with OpenAFS: it only supports des-cbc-crc:v4 principal keys, which means authentication is done using a weak encryption protocol. The other problem is that communication between afs clients and servers get encrypted using something even weaker: fcrypt.
In fact, this is something that confuses me: I thought that encryption of any two parties “talking” kerberos was done using the session key given by the TGS. But it seems that applications like OpenAFS bypass this, using their own encryption scheme. Or maybe the session key is used only for the mutual authentication part. In this case, what type of encryption protocol is used those messages? This whole thing about encryption leaves me confused…if someone cares to shed some light, it would much appreciated ![]()
But as far as I know, in the current network design that we were trying to mount (kerberos, ldap, openafs) the weak link is OpenAFS, because all the other principals can use of AES encryption type.
Nonetheless, this whole scheme of Kerberos plus OpenAFS plus OpenLDAP is just great to whom seeks to secure a smaller network within unsecured networks.
References
- http://docs.openafs.org/Reference/8/asetkey.html
- http://users.surfvi.com/~ota//fcrypt-paper.txt
- http://docs.openafs.org/Reference/1/fs_setcrypt.html
- http://web.mit.edu/kerberos/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#Supported%20Encryption%20Types
- http://en.wikipedia.org/wiki/Needham-Schroeder_protocol
- http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Client_Service_Authorization
- http://web.mit.edu/Kerberos/dialogue.html
- http://openafs.org/
- http://web.mit.edu/kerberos/
- http://web.fe.up.pt/~jmcruz/ssi/acetat/4-autentica.pdf
Post a Comment