How Kerberos was evolved - Inside Story Part 2

In my last post I discussed few steps for the evolution of kerberos protocol implementation. In this post I am going to conclude it so read on...

Just want to recolect the problem statements where I left in last post so you get some continuity

Problems

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

For solving first problem Authentication Server (Ticket Granting Server [TGS]) will generate a sessionkey which will be sent to the user. TGS will also send a ticket encrypted with service password to the user. Below is the detailed structure

[SesssionKey:[*Service Ticket encrypted with service Key]]

* Structure of service ticket is [SessionKey:lifespan:issuing time:service name]

issuing time and lifespan are introduced so tickets can be valid for specific amount of time and not good for ever.

TGS will encrypt session key and ticket with user's password to solve the replay attack because password is only shared between user and Authentication Server.

Step by Step process for user authentication and service access

1) User enters the userid and KINIT program on the user machine sends that to TGS for authentication.

2) TGS server creates Ticket Granting Ticket [TGT] (this will be used to get service tickets)and send to the user by encrypting the whole content by users passwod.

3) User decrypts the TGT using the password to get the ticket. If someone spoof the packet then he will not be able to decrypt it as the password is shared between user and TGS only.

4) User wants to access his mail but user does not have mail service ticket so user contacts TGT for mail service ticket by submitting Authenticator,TGT, Name of the user and workstation address. This Authenticator with the session key sent by the TGS in the initial handshaking.

* Authenticator = {username:servie name: time stamp : lifespan}

5) TGS will get the session key of the user and decrypts the authenticator. After validating the identity it generates following and send by encrypting the whole content using the SESSION Key.

i) Ticket for the mail service. This ticket has the session key, service name, lifespan, timestamp and client address. This ticket is encrypted with the service password. (Even User can not decrypt it)
ii) Session key to be used to encrypt the conversation with mail service

6) User recieves the packet and decrypts the content using the session key (Given during first handshake with the TGS).

7) User prepares the Authenticator and encrypts it with the SESSION key (generated for the mail service communication in step 5).

8) Mail Service recieves the Authenticator and Ticket. Decryptst the ticket using it's password to get the session key. Using the session key decrypts the Authenticator. Validate the Authenticator and sends the acknowledgement to the user by encrypting the session key.

9) User receives the acknowledgement and start using the service.

How Kerberos was evolved - Inside Story Part 1

I always wanted to get something on kerberos (earlier name Charon) which can give me inside of the protocol like why,how, what etc...

In this post I am trying to explain this in some easy steps with problem and solution approach for the evolution of this protocol.

Below Image displays the first version of there discussion



Problem with the first version is that anybody can impersonate anybody easily so no security and accountability. There is no Authentication (NO PASSWORD) piece involved it is just the userid which you pass to get the service.

Below Image solves first problem by having a centralized authentication server. Every user and every service has a password which is stored in the authentication server named CHAROS.

Here is how it work

1) User Authenticates with the centralized server
2) Server authenticates the user and give him a TICKET (encrypted text which is encrypted with service password)

*encrypted text contains (Username and servicename and IP address of the user)
3) User passes this ticket to the service and service will verify user's identity to give access




Problems with this:

1) User has to authenticate every time user wants to use any service. For example user has got the TICKET for mail service but wants to print some mail then he has to again enter the password
2) Password is flowing on the network in clear text (people can capture the password on the network)


Above problem is solve by introducing another component called ticket granting service in the authentication service. It will grant the ticket which can be reused.

Another componet which is added at the system level is KINIT service which is responsible for handshaking with the authentication service. Here is how it works

1) KINIT service will take userid and password from the user and will pass the userid to the authentication service (it will NOT pass the password at all)
2) Authentication service will build the TICKET GRANTING TICKET and encrypt it with the user's password because it knows what the user password is.
3) KINIT will decrypt the token using user's password. If it is able to decrypt it successfully then user is authenticated.





Problems:

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

Keep reading this because I will post rest of the story in next post...

How SSL Hand Shake works???

The purpose of the SSL Handshake is a multifaceted one. It involves server (and optionally client) authentication, determining what cryptographic algorithms are to be used, and the generating of a secret key by which all future SSL Data Exchanges are to be encrypted by. The steps by which this is accomplished are as follows:

Client Hello
The main purpose of the client hello is to inform the server of what cryptographic algorithms the client can support and to ask for verification of the server's identity.

The client sends to the server three things:
· Set of supported cryptographic protocols.
· Compression algorithms.
· Random number.

The purpose of the random numbers is if the server does not have a Digital ID, a secure connection can still be made using a different set of algorithms(like Diffie-Hellman), although it is impossible to verify their identity.

Within the set of cryptographic protocols there is the Key Exchange protocol (how we are going to exchange the information), the secret Key algorithms (what encryption methods can we use), and a one-way hash algorithm. No secret information is passed at this point, just a list of choices


Server Hello
The server responds by sending the client it's Digital ID (which includes it's public key), the set of determined cryptographic and compression algorithms, and another random number. The decision as to which cryptographic algorithms are to be used is based on which ever are the strongest that both the client and server support. In some situations, the server may also ask the client to identify themselves as well (by requesting a Digital ID).

Client Approval
This step involves the clients browser checking the validity of the Digital ID sent by the server. This is first done by decrypting the Digital ID using the Public key of the certificate's issuer and determining that the certificate comes from a trusted certificate authority. After it has been decrypted, a series of validity checks occur. This includes checking validity dates and making sure that web page URL matches the one listed in the certificate.

Once the server's identity has been verified, the client randomly generates the secret key and encrypts it using the server's public key (Server has sent this to Client in first step) and the previously determined cryptographic and compression algorithms. The client then sends the encrypted secret key to the server.

Verification
At this point both parties know the secret key. The client knows the secret key because the client generated it, and the only other person who knows it is the server, because a message encrypted with the server's public key can only be decrypted by the server's private key. A final check is done to ensure that the previous transfers have not been tampered with. both parties send a copy of all the previous transactions encrypted with the secret-key. If both parties confirm the validity of the transactions, the handshake is completed. Otherwise the handshake process is re-initiated.

Both parties are now ready to communicate securely using the agreed upon secret-key and cryptographic/compression algorithms. The SSL handshake is only done once and the secret-key is used for only one session.

Graphical Representation of Steps

Technorati : SSL handshake

Commonly used openssl commands

Here I am giving some of the commonly used openssl commands.


• Generate A Certificate Signing Request
openssl req -new -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcsr.pem
• Create A Self-Signed Certificate From A Certificate Signing Request
openssl req -x509 -days 365 -in hostcsr.pem -key hostkey.pem -out hostcert.pem
• Generate A Self-Signed Certificate From Scratch
openssl req -x509 -days 365 -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcert.pem
• Generating a certificate using the ca certificate generated above
openssl x509 -req -in sonycsr\ldapssllocal.pem -CA sonycerts\ca.pem -CAkey sonykeys\cakey.pem -CAcreateserial -out sonycerts\ldapssl.pem -days 1024
• View The Contents Of A Certificate Signing Request
openssl req -text -noout -in hostcsr.pem
• View The Contents Of A Certificate
openssl x509 -text -noout -in hostcert.pem
• View The Signer Of A Certificate
openssl x509 -in cert.pem -noout -issuer -issuer_hash
• Verify A Certificate Matches A Private Key
openssl rsa -in key.pem -noout -modulus
• Find The Hash Value Of A Certificate
openssl x509 -noout -hash -in cert.pem
• Create A Private Key
openssl genrsa -des3 -out key.pem 1024
• Encrypt A Private Key
openssl rsa -des3 -in hostkeyNOPASSWORD.pem -out
• Decrypt A Private Key
openssl rsa -in hostkeySECURE.pem -out hostkeyNOPASSWORD.pem
• Convert PEM Format Certificate To PKCS12 Format Certificate
openssl pkcs12 -export -in cert.pem -inkey key.pem -out cred.p12
• Convert PKCS12 Format Certificate To PEM Format Certificate
openssl pkcs12 -in cred.p12 -out certkey.pem -nodes -clcerts

Technorati : openssl commands