 Good morning everyone. Today we are going to talk about we are going to continue our discussion of security protocols that we began yesterday. We will talk about transport layer security or SSL. We will have a demo on SSL and then we will also talk about Needham Schroeder and Kerberos. So, before that let us just summarize what we had done before. So, we looked at basic authentication different kinds of variations first and foremost there is one way where one party authenticates himself or itself to the other party, but not necessarily the other way. And then you have got two way or mutual authentication. In addition to that you could have authentication on the assumption that there is there are long term secrets shared between the two parties. The other assumption is one or more parties has a digital certificate. So, we took various combinations one way with a long term secret, one way with a certificate, mutual authentication with long term secrets and then mutual authentication assuming a digital certificate or both sides perhaps having digital certificates. Then we looked at the next thing the next enhancement to this which is entity authentication. So, all of this is entity authentication as opposed to message authentication. We then look at looked at entity authentication in conjunction with session key agreement. And then finally, we looked at the use of nonces or time stamps or both. So, those are very basic authentication protocols that we considered, but they are the building blocks of various widely used protocols today and some examples of these would be. So, this is the protocol for use on the web SSL, this is at the transport layer. Then we have IPsec which is at the network layer. Then we have got various wireless protocols for wireless LANs. For example, WPA 802.11I actually and then other wireless protocols for cell phones. For example, the 2G, 3G, 4G etcetera. So, all of these have the building blocks of all of these protocols are indeed what we considered yesterday. We will now move on to take the first of these which is SSL secure socket layer. So, another name for SSL is transport layer security TLS history. SSL has emerged as the principal means of securing communications between an internet client such as a browser and a server. So, its roots go back to the mid 1990s by a company called Netscape which was in the browser business. It was standardized by IETF in 1999 and was called TLS or transport layer security. Today these 2 acronyms are used interchangeably secure socket layer and transport layer security. So, where does SSL sit on the network stack? SSL is typically sandwiched between TCP. So, it only runs over TCP and some application layer protocol such as HTTP, FTP, SMTP, IMAP etcetera. Typically when SSL is used the application protocol is suffixed with an S. So, for example, HTTP S as opposed to just HTTP. So, you are in a picture this is the application layer, this is the transport layer and between the 2 sits this SSL and the SSL protocol itself has got two parts. The most important one the SSL handshake protocol and then the other important one the SSL record layer protocol. In addition the SSL handshake protocol you have another protocol that acts as the when you move from SSL handshake to SSL record layer protocol you typically go through this change cipher spec protocol which is actually one of the messages as we will soon see. So, once again the 2 layers the handshake protocol and the record layer protocol. So, we are going to discuss in detail what is this handshake layer protocol all the different messages and then when you come to the lab in the afternoon you will actually use wire shark to inspect all those messages to inspect the digital certificate etcetera etcetera. So, what does SSL provide? So, we saw different things yesterday like authentication, integrity, confidentiality, non repudiation etcetera etcetera. So, which of the following is provided by SSL? So, server authentication this is absolutely mandatory for SSL then client authentication this is an option. So, you do not necessarily have to have that. So, visualize internet banking you have got the customer and then you have got the bank. So, typically what happens as part of the record as part of the handshake protocol the bank authenticates itself to the customer and the customer authenticates itself to the bank it has to of course. So, the customer authenticates itself to the bank in the record layer protocol. So, this is actually optional in the handshake protocol, but of course, it is mandatory overall. So, this is actually done very often you by the use of passwords after the secure tunnel has been created by the SSL handshake protocol. Then there is message authentication as we know these are very important entity authentication. So, this is actually entity authentication and now we have got message authentication where you take every single message and you protect it both you must be sure who the message is coming from and you should be sure that the message has not been tampered with en route to the destination. So, this is entity authentication and this is message authentication and then this is integrity checking. Message confidentiality it is not the case that all the time you require confidentiality so an option is provided do not forget confidentiality takes place through cryptography and that can be expensive. So, there are times where you may not need it and in that case it is shut off and then finally, non repudiation. So, if both sides had digital certificates then you could have non repudiation, but typically it is the case that the server has a certificate, but most clients do not. So, because a client does not have a digital certificate it is more or less difficult or impossible to actually guarantee non repudiation. So, what are the main things that happen as part of the SSL handshake? The first thing is the agreement on a common cipher suite. So, what does a cipher suite actually encompass? It includes all the algorithms that you use. So, think of all the things that might you might want to do, you might want to agree on common keys. So, which key exchange method should I use? Yesterday we had seen Diffie-Hellman key exchange, should I use Diffie-Hellman based key exchange or RSA based key exchange or something else. We need to compute integrity checks those are typically done through the use of a keyed hash, which hash function do you use MD5, SHA1 etcetera. I would typically if I need confidentiality I would need to encrypt messages as they go from party to one party to the other. Would I use DES? Would I use AES? Would I use triple DES? Would I use RC4 etcetera? All of those things have to be negotiated as part of the SSL handshake protocol and all of those get included in what I call the cipher suite. So, both sides negotiate and agree upon a common cipher suite. The next important thing that needs to be done is the server side has to send a certificate to the client and that certificate should be validated by the client. So, you have to check whether the certificate actually pertains to that server, you have to check the validity period, you have to check the signature on the certificate etcetera etcetera. So, all of that thing needs to be done. The next thing is how do you actually agree on common keys. So, SSL has a very nice idea of a pre-master secret. So, typically the pre-master secret is determined by the client and then encrypted and sent off to the server side. Encrypted with what? Encrypted with the servers public key and the servers public key is contained in the certificates sent by the server. So, the server decrypts that this message and retrieves the pre-master secret from that message. And then finally, integrity verification of all the handshake messages, how can I be sure that each of those handshake messages. So, typically except for this thing all the other handshake messages are sent in the clear. How could I guarantee the integrity of each of those messages? And finally, and one of the most important is how am I absolutely sure that the other end is the server I intend to talk to and not somebody posing as that server. So, just because from the other end I get a certificate which has the servers name on it does not at all mean that I am really talking to the authentic server. Because that server certificate is all over the place and anybody could use it and send it to you and you would think it is the bank that you want to talk to. So, clearly that is not enough just producing the certificate in this message, you need to actually prove that you are the owner of that certificate. You are indeed the principal whose name is mentioned in that certificate. So, these are the messages and as I said again you will be in the lab today. We also have a demo of all this, you will be in the lab and you will actually see all these messages using wire shot. You will see the content of each of those messages and all of this will come alive. What is inside the client hello message, the server hello message, the server certificate etcetera. So, this is the client key exchange I mentioned the pre master secret. So, that pre master secret is encrypted with the servers public key which is contained in the server certificate and that encrypted pre master secret is sent to the server which is decrypted on the server side and from that pre master secret you derive master secrets and six other secrets that I am going to mention a little later. The chain cipher spec message goes between actually transits between this protocol. We talked about the handshake protocol and the chain cipher spec protocol. So, this message actually provides the transition between the two protocols before we start moving to the record layer protocol. So, once the handshake protocol is completed and this chain cipher spec message and the finished message then we move to the next protocol which is the SSL record layer protocol. So, this is purely for entity authentication and for key exchange. Once we have agreed upon the keys then we go on into the record layer part of this thing where we will start exchanging messages which will also have integrity checks on them. So, a MAC kind of thing and if necessary they will also be encrypted, but with which session key will they be encrypted which key will you use for the keyed hash all of that is determined in these steps. So, we talked about these messages let us look at it once again what is the sequence of messages there is a client hello and then there is a server hello and a server certificate. So, let us focus on these two messages what could be inside these messages. The information exchange in the hello messages the algorithm to be used in computing the MAC. So, this is what I need to state when I say I I mean the client the clients or the clients browser the user's browser needs to state what is the algorithm to be used for computing the MAC. For example, MD5 and SHA1 are two options there are many others like for example, SHA256 if you want higher security whether or not message confidentiality is required and if so which of these algorithms say DES triple DES AES RC4 etcetera. And then if you are using say AES there are different key lengths. So, which key length do you insist on then the key exchange method for communicating the pre master secret. So, there is Diffie-Helman key exchange you can do key exchange by you simply using RSA and so on. So, which method do you want to use and if you are using Diffie-Helman key exchange then which group are you using there are several groups for this including elliptic curve groups that is points on the elliptic curve. So, which of these groups do you want to use you meaning the client and which of these groups is recommended by the server. So, they both will present their own options and finally, agree on one set of each of these things. And another important thing do not forget is these 32 bit 32 byte nonces which you will be seeing in the demo. So, actually it is a 28 byte nonce and there is a time stamp. So, the entire thing is about 32 bytes. So, there is a nonce that is provided by the client which is nonce R A and then there is another nonce chosen by the server which is R B. Now, what is the purpose of this in these nonces you might want to think about what could these nonces be used for a very interesting idea. So, it turns out that this pre master secret is chosen once and then as a function of the pre master secret you compute the master secret. The master secret is a function of that pre master secret and of these two nonces. So, if I keep the pre master secret fixed for the duration of the session I can keep changing these nonces from time to time. So, that I get a new set of keys and make the job of the hacker more difficult. It is a good idea to refresh the session keys within a certain interval of time rather than keeping that same key for the complete duration of the session which might be several minutes for example, I would like to change it every few seconds. I do not want to incur a big overhead when I change the master secret. Now, it turns out that this exchange of the pre master secret is actually a time consuming operation as we will soon see. So, if I keep that fixed, but if I vary the two nonces then I can derive a new master secret a lot more efficiently ok. So, we talked about the first two messages which were the client hello and the server hello. The third message is the server certificate. So, the server communicates its certificate to the client on receive of the certificate the obvious things are done. The client checks the owner's name credentials the URL etcetera. For example, the validity period the signature of the C A on the certificate. So, this is a certificate that you are doing internet banking with the state bank of India. You will check and see who is the C A that has actually signed SBIs certificate and you will verify the signature of the C A. When I say you will do it it means your browser will do it ok. The next thing is client key exchange. So, let us get back to that picture so that we can recall where this is. Client hello, server hello, server certificate once again what is in this message a cipher suite which algorithms I am willing to support. There is also a session ID inside this and there are the there is a nonce from the client side and in this there is a nonce from the server side and again a statement of which crypto suite I am willing to support. And then there is a server certificate now we go to this client key exchange. So, this is the pre master secret I was talking about and you can actually you can actually see this in via shark because it is going to be encrypted, but it is a 48 byte random number. So, the client chooses a pre master secret a 48 byte random number. This is encrypted with the servers public key notice that the public key was obtained in the server certificate and sent. So, the pre master secret is encrypted with the servers public key which is contained in the servers certificate which was sent to the client and this encrypted thing is sent to the server in the client key exchange message. The server uses its public key to decrypt the encrypted pre master secret. So, this is a misprint over here it should be the private key. So, the server uses its private key corresponding to the public key in the certificate to decrypt the encrypted pre master secret. Now, one way of doing this is to use simply RSA. So, I use RSA and the servers public key to encrypt the message and here the server uses its private key to decrypt the message. So, this is a misprint it should be private key. Now, as you might be aware in RSA the private key operation is much more time consuming compared to the public key operation and both of them are much more time consuming compared to a secret key operation using secret key cryptography. So, RSA is more time consuming much more time consuming compared to for example, AES or DES. So, this becomes a critical step this decryption step because it takes a long time. So, that is why I mentioned before that a good idea is to have the pre master secrets and just once. From this you derive the keys based on the nonsense and so on and then you change the nonsense after a few seconds for example, and then re derive the master secret keeping the pre master secret fixed. So, here is the actual expression without getting into unnecessary details both the client and the server compute the master secret from this expression. So, what is this function? This is a so called 0 random function it basically like a cryptographic hash which takes as inputs the following. So, the master secret is a function of the pre master secret it is a one way function like a cryptographic hash of the pre master secret and the nonsense that were chosen by the client and the server and then some predetermined constants. So, from that I compute the master secret. So, I can get a new master secret if I keep this thing fixed and just vary these two things I would like to keep this thing fixed because communicating this and decrypting this and so on takes a lot of time. So, from time to time I will change the master secret how only by changing these two values even though this thing is fixed and why do I want this thing fixed because it incurs a lot of overhead. So, here f is an h max style function while the constants are predetermined values known to both client and server ok the derived secrets. So, now from once again from the master secret from the pre master secret I derived the master secret and from the master secret I am going to derive six different secrets that both sides both sides will actually derive them. So, these are secrets known to both sides the browser and the server. So, what are these secrets the initialization vector for encrypting messages from the client to the server. So, as we have seen before in the case of say CBC that is a desk in CBC mode you require an initialization vector to start the entire thing. So, these initialization vectors will be derived from the master secret then the secret itself for encrypting messages from the client to the server and another one from the server to the client. So, the key that is used for messages from client to server is different from the key that is used from server to the client and once again the initialization vector for encrypting stuff that goes from the client to the server that is one initialization vector that is this and then from the server to the client that is the other one. And then finally, do not forget one of the most important things is to integrity protect every message and we do that using the Mac another term for that is the keyed hash. So, because it is a keyed hash you need a key. So, secret for computing the keyed hash or the Mac on messages from the client to the server. So, the server Mac secret and a client Mac secret. So, both sides should know all these six secrets to be able to encrypt and decrypt or to be able to integrity protect and to verify the Mac. So, I mentioned before in the transition between the SSL handshake and the SSL record protocol there is another protocol that you momentarily go through and that is the chain cipher spec protocol which is triggered by this chain cipher spec message. So, both parties create and transmit a chain cipher spec message this message signals a transition that from now on the cipher sweep just negotiated and the keys just computed will be used and then there is a finished message. So, let us just go back to that picture just to make sure we understand where these things fall in place. Client hello server hello server certificate communication of the pre master secret and now this chain cipher spec message which basically signals that from now on we will start using the keys that we have just derived and let us see these two important messages the finished message. So, let me just say before that this finished message is going to contain a Mac a Mac computed in all these protocols now the thing is all of these messages except for this one all of these messages are in the clear. So, what prevents the hacker from coming in the middle over here a man in the middle attack and changing certain things. So, to prevent that from happening what you do is you integrity protect them so that even if somebody tempers with them you can detect the tampering. So, that is why you will compute in this finished message you will compute a Mac from this end and send it across and the same thing will be done in this finished message he will take all these messages string them together and compute a keyed hash or a Mac and all those messages and send the Mac in this finished message. So, this guy the client is sure that he is talking to the right server. So, this is the important component in the finished messages. So, both sides communicate a finished message to the other the finished message includes a keyed hash on the concatenation of all the handshake messages send in the preceding steps together with the predefined constant. The keyed hash serves as an integrity check on all the previous messages. So, there are two aspects of this the integrity checking and just as important the authentication especially the authentication of the server to the client. The client to the server authentication takes place to the password as part of the SSL record layer protocol. So, the handshake basically creates a secure tunnel and across that tunnel the client sends its password. So, how is actually server authentication how can I be sure if I am the client how can I be sure I am talking to the right server. So, at what point precisely does the client authenticate the server as I mentioned before it is incorrect to say that just because I received a certificate from somebody I conclude that that guy that I received the certificate from is the actual principle on that certificate. For example, take a particular banks HDFC bank. So, many people receive HDFC bank certificate. So, you can just take that certificate and send it somebody can take that certificate and send it to you just because you have received that certificate from that person does not mean that person is HDFC bank. So, it is much more than that server authentication is just more than is much more than just receiving the certificate from the server. So, when does the actual serve when can I the client be sure that I am talking to the right server. So, here is the logical steps the key used in the keyed hash contained in the finished message is one of the six derived keys. So, I mentioned before there are six derived keys including one of the keys is two of the keys are to compute the keyed hash one for client to server communication and the other for server to client communication. So, the key used in this is one of the six derived keys. So, unless I know those keys I cannot compute this and to know those keys where did I get those keys from the server computes the key from the master secret. So, unless I know the master secret I cannot compute those six keys unless I compute the six keys I cannot correctly obtain this keyed hash and to obtain the master secret how did I obtain that the encrypted pre master secret could only be decrypted using the servers private key. So, unless I could decrypt that key message you remember the message over there after the server certificate unless I could decrypt unless the server could decrypt that message he could not obtain the pre master secret. So, the only way he can decrypt it is by being in possession of his private key. So, if he has the private key he can decrypt the message and obtain the pre master secret. If he obtains the pre master secret he can derive the master secret how because this thing is a pseudo random function of the pre master secret and the two non cells. And once you obtain this once again using a pseudo random function you can obtain all those six secret and one of those secrets is used to compute this keyed hash. So, once I get once the client gets the correct keyed hash and verifies it then and only then he concludes that he is talking to the right an authentic server. So, by verifying the keyed hash from the server the client is convinced of the authenticity of the server ok. So, now we talked about sending this pre master secret and there are rich number of ways in which you can actually exchange the key. So, as mentioned before the client chooses the pre master secret and encrypts it with the servers public key obtained from the server certificate. It is possible that the server certificate may be used exclusively for signing. So, as I mentioned yesterday there are some certificates that should be used only for signing that is the corresponding private key corresponding to the public key in that certificate should be used exclusively for signing anything else. So, in that case what should I do the server has a certificate, but that is a signing only certificate. So, in that case what he can do is the server may generate a public key private key pair and a femoral public key private key pair and then sign this saying that it is I who came up with this pair I sign it with the public key contained in my signing only certificate. So, I sign it with the private key corresponding to the public key in my signing only certificate that is what I will send across. So, the server may generate a public key private key pair sign the public key parameters and send the public key to the client with this signature only certificate. So, there are so many different options and of course do not forget that you can use multiple Diffie-Helman options as well you could have a certificate with the Diffie-Helman parameters in them and so on. So, we had seen this yesterday the server may instead communicate a Diffie-Helman certificate which includes a signed copy of g p and g raise to a mod p signed by the C A g p and g raise to a mod p this is the public key. The client chooses a random integer b computes g raise to b mod p and sends this to the server the client computes then g raise to a mod p to the power of his secret b over here and this g raise to a mod p came from the server certificate. So, it takes the public key of the server and raises it to the power of his secret and the server does takes the g raise to be the partial key which is sent by the client and raises it to the power of a which is his secret. So, the server secret is little a or the servers private keys little a and the corresponding public key of the servers g raise to a mod p which is contained in the certificate together with the Diffie-Helman parameters. So, both sides agree on a common pre-master secret g raise to a b mod p there is also another nice idea in the context of SSL and that is the idea of a session and a connection which is basically what I tried to explain before. So, it is good security practice to change keys during a long lasting session. So, you refresh these keys do not keep the same key for say several minutes try to refresh it even though the session might take several minutes, but you refresh it. Now, SSL has provisioned for changing the keys by creating new connections within an existing session. So, far the largest component of the overhead in creating a new session key is the RSA private key operation basically RSA decryption of the pre-master secret at the server side. So, can I somehow obviate the need for this this overhead is obviated by creating a new connection within an existing session. The new master secret will be as every as we know the master secret is a function of the pre-master secret and the two nonces the pre-master secret remain the same by keeping it the same I guaranteed that the server would not have to go through the headache of doing another decryption which takes so much time. So, I keep the pre-master secret the same, but I change the nonces. So, I have a client hello and a server hello to change the nonces because the client hello the server hello contains those two nonces R A and R B and those are used together with the pre-master secret to obtain the master secret. So, thereby I have changed the six keys by only changing the master secret and not the pre-master secret because the master secret is a function of the pre-master secret and the two nonces. So, once again this thing is summarized over here in creating a new connection the pre-master secret which is part of the existing session state is not chosen an new because that would incur an overhead. Instead a new master secret is computed as a function of the existing pre-master secret and two fresh nonces contributed by client and server. So, it is very good security practice as we saw yesterday for both sides to contribute towards creating the session key. So, we used SA and SB in the protocols yesterday. So, here also both sides contribute R A and R B towards the master secret and finally, the SSL record layer protocol. So, this is the handshake and all the trouble we had to go through to obtain these those six keys and also do entity authentication in particular authentication of the server. Now, once we are through with all that we can simply go ahead and integrity protect every single message and if necessary encrypt every single message. So, that is done as part of the SSL record layer protocol. I already have the keys now I can just go ahead and compute the MAC for each message and optionally also encrypted. So, the SSL record layer protocol is used to securely transmit data using the negotiated cipher suite. So, we have just done that in the handshake protocol and we also derive the keys as part of the handshake. Now, we go to the record layer protocol whose main tasks are computation of a per message MAC and encryption. So, this is a distinction between entity authentication and message authentication. Entity authentication took place in the at least server authentication took place in the handshake and per message authentication and integrity protection takes place as part of the SSL record layer protocol using the keys that were computed and derived in the handshake. In addition if the data to be transmitted is very large it performs fragmentation each fragment is 16 kilobytes or less. So, it is the duty of this guy to do the fragmentation besides the all important duties of protecting every message in transit by protecting I mean integrity protecting guaranteeing the integrity of it against tampering and so on and also encrypting if indeed that is necessary. So, with that brief introduction to SSL let us now move on to complete this discussion of security protocols. We will now look at a different kind of protocol which uses what is called a KDC or key distribution center. So, prerequisites for authentication between two parties we have assumed that both sides share a secret or that one or both sides has a public key private key pair. Let us get back to SSL and see what were the assumptions made over there. The fundamental assumption is that the server has a certificate, but the client does not. So, either there is a long term secret that both share or there is a certificate. So, in the case of internet banking the server has a certificate and the client the user has a long term password that he shares with the server. So, in the former when you talk about using certificates or you talk about secret keys key management is a problem. We have seen this before in secret key cryptography key management is a problem and in the case of public key cryptography certificate based authentication etcetera performance is a problem because RSA operations are very expensive. So, is there some sort of an alternative approach which handles both and here we come to the role of the KDC. So, a third approach is to employ a trusted third party which functions as a key distribution center. So, what is this KDC? Each user registers with the KDC and chooses a password. So, we assume for example, a campus where you have got multiple users and each of those users to use the facilities has to enroll with this KDC. The user has to choose a password which is basically a long term secret and the key is a function of the password. So, some sort of PRF pseudo random function of the password and maybe some predetermined constants and that is exclusively shared by the user in the KDC. So, basically the user has the password and then the system the password software will actually convert the password into a key and that key will be used to for example, authenticate the user to the KDC. So, the main function of the KDC is to securely communicate a fresh common session key to the two parties who wish to communicate with each other. So, let us see how actually that works. So, the main function of the KDC is to authenticate the user and basically communicate in a secure fashion a common session key to the two users. So, that they can communicate securely for the duration of the session. So, this is the key distribution center these are the two parties. So, let us see how the communication might what the communication might be. So, A says I am A and I wish to communicate with party B and then what the KDC does is it actually sends a session key to A encrypted with A is long term the long term key that A shares with the KDC. So, that A over here means encryption using a function of A's password. So, both A and KDC can decrypted. So, KDC has encrypted the message and A can decrypt the message and nobody else can read that message or understand it because it requires knowledge of A's password. In the same way KDC also sends the same session key encrypted with B's password to B. So, only B can read it. So, now both A and B have access to this KAB the session key and they can communicate with each other securely using that session key for the duration of the session. So, the KDC chooses a fresh session key KAB which is this thing it sends this key to A after encrypting it with A's long term key KA likewise it sends this key to B after encrypting it with B's long term key KB. Now, there are several problems with this approach which you will find for example, one of the important things is the lack of synchronization this guy might receive the key this guy might receive it after a long delay etcetera etcetera and there are many other attacks that are possible like the man in the middle attack and replay attacks etcetera. So, let us try to improve on this and see whether an improved version of this thing is vulnerable or not to other kinds of attack. So, an attempt to do this was by Needham Schroeder called the Needham Schroeder protocol. So, here is what it looks like. So, here is the party A that wants to initiate communication here is B. So, A wants to talk to B and here is the KDC. So, the first message is between A and the KDC hi I am A and I would like to talk to B. So, basically provide both of us a session key that is basically what he is saying authenticate me and provide a session key to both of us and. So, that nobody else has that session key. So, what does this guy do? He creates what is called a ticket. So, this ticket contains. So, this ticket is going to be. So, this is the important thing the ticket that is eventually going to be given to B. So, you will see that this is received by A and forwarded by A to B. So, what does this ticket contain? As you might expect it will contain the session key it will contain the identity of the other party. So, this is. So, basically this guy is telling this guy that I am enclosing here with this ticket a session key for the duration of the session with party A and. So, that nobody else can read it I am encrypting it with the long term key that you Mr. B shares with me. So, this is the ticket and together with the ticket of course, he also encloses the session key as another part of this message and encrypts the entire thing with is long term key. So, that only A can read it. So, when this message goes to A, A decrypts it he gets this session key and then he gets this thing. Of course, he cannot see what is inside this because it is encrypted with B's long term key. So, he receives this entire thing and then he sends that ticket basically just this thing is simply forwarded after being decrypted and then he sends a nonce which is R 1 in this case. So, basically he is telling him here is my challenge to you if you are really this guy then decrypted using the fresh session key and decremented by one and send it back to me after he encrypted. So, basically what will be do there are two parts of this message this thing and this thing. So, we will take this B has his own long term key. So, with his long term key he will decrypt this he will realize that A wants to talk to him and that A has already communicated with the KDC this ticket has come from the KDC he will pull out the session key. Now, with knowledge of the session key he will be able to decrypt this nonce this A B over here means that this message is encrypted this nonce has been encrypted by A with the common session key. So, if he is really the good guy he will be able to decrypt this he will be able to retrieve this session key and with the session key he will be able to retrieve this nonce. So, once he does all that work he will then create a message which contains that nonce decremented by one and a fresh nonce which serves as a challenge to A. So, basically B is saying I have responded to your challenge I have been able to obtain R 1 because I am the right guy I am decrementing it and setting it back to you for verification and I am also enclosing a nonce which is my challenge to you this R 2. So, he sends this thing and then in response what she will do is she will decrypt this thing because she has the session key she will retrieve the R 1 minus 1 verify that this is a decremented version of the nonce that she chose and then she will take the nonce that he chose decremented by one and send it to her encrypted with this. So, that then he will realize that she is the authentic A. So, this is the version the first version of the protocol. So, I am not the intention is not really to look at every single attack on this protocol because that would take a long time it is just to show you that even though this protocol looks correct and there actually are bugs in it and it is not very easy to always detect the bugs. So, let us see one possible bug some sort of a man in the middle attack for example. So, this is basically just a explanation in words of what was going on over there. So, the question that is floating in our minds is how can we actually attack this protocol it looks pretty sound. So, once again this is what it looks like I am A I want to talk to B give me a session key for myself and for the other party. So, this guys retrieves A is long term secret from a database and B is long term secret that is basically the passwords function of the passwords and from that he creates this message first and foremost he creates a ticket to be given to B. So, he generates a session key K A B creates a ticket to be given to B which contains the identity of A and the session key encrypted with B is long term secret and puts that stuff together with the session key in a bigger message which is encrypted using A is long term secret sends it to A A starts to decrypt this entire thing he retrieves the session key and then he retrieves this token he cannot make any sense of this token because it is encrypted using B is long term secret. So, whatever we accomplished over here A has now received the session key because he can decrypt this message the A over here means encrypted using A is long term secret or password that he shares with the KDC the A B means a session key to be shared only for the duration of the session between A and B. So, then what A does after he is retrieved this thing he just simply forwards that stuff and then he now says he wants to challenge B both have to challenge each other. So, he challenges B and says here I am generating a fresh nonce the word fresh is very important so that there is no replay I am generating a fresh nonce R 1 and I am encrypting it with the session key I am sending it to you. If you really are B what can you do what are the things you are supposed to be able to do if you really are B you are supposed to be able to decrypt this ticket and obtain the session key. Because I understand that KDC has encrypted the ticket with the long term secret that you share with the KDC. So, if you really are the right guy decrypt this and obtain K A B once you have obtained K A B read what is my nonce obtain my nonce decremented by one and re-encrypted and send it send it to me. So, that I can be sure you are really the right guy. So, what he does he decrypts this he gets the session key he decrypts this thing with the session key that he is just retrieved and then he from that he retrieves this R 1 challenge. He takes R 1 decrements it by 1 and then adds his own challenge to A which is R 2 and says now I challenge you if you are the right person you should be also able to use the same session key that was given to both of us use that session key decrypt this and obtain these two things. The first thing is a verification so a response. So, the first thing he does is he sees what is inside this after decrypting it is this really the challenge minus 1 then I am convinced that this is indeed B and then I will issue my own I will respond to the challenge from B. So, I will take the challenge R 2 decremented by 1 and then encrypted using the session key and send it to B and then B will decrypt this and verify whether what is inside over here is the nonce that he chose minus 1. So, again this is a fresh nonce if everything works out then it appears that they will be sure there is no replay etcetera and this this K A B is a fresh key that was given by the K D C. Unfortunately many of these protocols are very treacherous and they could be bugs in them. So, let us see what is the bug in this protocol. So, here is the standard man in the middle we have already encountered a man in the middle attack in connection with the Diffie Helman key exchange yesterday. Now, here is another version of this thing. So, A sends the first message I am A I want to talk to B and there is an attacker who now stands in the middle intercepts this message and changes it changes the B to an X. So, basically he is telling the K D C I am A impersonating A and I want to talk to X who is X X is himself and the K D C receives this message. So, he can choose a different you know go to a different machine or something like that. So, K D C does not realize that X is saying that he is A and the D wants to talk to X. K D C is not able to figure out that he has spoofed this message basically the K D C only goes by things like keys. So, he accepts it that I am receiving a message from A and that A is saying he wants to talk to X. So, what does he do? He prepares a very similar kind of message he will encrypt he will create a token or a ticket which contains the session key and the identity of A because A wants to communicate. So, A is the initiator initiators ID over here the session key and he will encrypt the ticket with X is long term key. So, this is X over here and sends it across to A, but before that he also encloses the session key and the two things together this pair of things is encrypted with A is long term key that that is shared with the K D C. So, A is able to retrieve it A and only A can decrypt this message and obtain this thing. So, what is the next thing that happens? So, now A sends the forwards this thing to supposedly B. So, A is thinking that he is actually talking to B X stands in the way intercepts the entire thing and guess what K D C was made to believe that A wanted to talk to X. So, therefore, he encrypted this ticket with X is long term key. So, X is very happy he stands in the middle he takes this message and because it is encrypted with X is long term key he can very happily decrypt that message and retrieve the session key. So, he retrieves the session key and then chooses a nonce encrypts it with a session key and says I challenge you to decrypt it and so on and so forth. So, the rest of the protocol is as before and so she is able to decrypt it and then she responds to his nonce which is R 2 in this message. So, why is A convinced that she is talking to B because A issued a challenge over here which is R 1 and X successfully responded to that challenge R 1. So, therefore, X is convinced that she is talking to B when she is actually talking to X. So, the standard man in the middle attack and now all the communication will go on between them and X will know everything that is that she wants to send to supposedly B. So, to get rid of this problem and there are actually several problems several kinds of attacks. So, look at the text for more of these attacks and this is the final version actually there might be some typos in this please bring it to my notice if you see any typos. So, it is a slightly larger protocol with more messages. So, it is interesting to see what is happening over here. So, now A actually initiates the communication to B saying I am A just by the way just to inform you that I am going to start I would like to talk to you. If he also wants to talk to her then he will send a message now very interesting message for in the interest of preventing replay attacks I would generate fresh nonces. So, I generate a nonce which is R 4 I cannot see this very well, but I think it is R 4 out there. So, a nonce R 4 and then I encrypt it with my long term secret that I share with the KDC. So, I send this message across to A and A simply forwards this. So, basically what he is saying is the ticket that the KDC sends me should bear should also have this R 4 inside it then I will know for sure that it is come from the KDC. So, he encrypts this because only the KDC can decrypt this message and retrieve the R 4. I am not able to see those numbers very well ok great yes. So, this is A and B and this is R 4. So, the this guy B he puts R 4 out there encrypted with the long term secret that he shares with the KDC. So, now this goes over there and A send sends a message to the KDC saying I am A I want to talk to B and by the way just to make sure that this whole thing is fresh whatever is your response I am also including a nonce that I just generated and I am enclosing an encrypted nonce that B just generated. So, there is no confusion later on. So, that nonces R 4 and encrypted with B is a long term secret and my nonces R 3 sending it to the KDC and then the KDC responds with this jumbo message which must contain a ticket. So, there is another brace over here that is not in this. So, the ticket is encrypted with B is long term secret as before. So, this is a ticket to you Mr. B since A wants to talk to you I am enclosing the identity of A I am enclosing the session key and then just to convince you that this is not a replay kind of thing you generated a nonce over here I am enclosing that nonce just to convince you. So, this is the entire ticket now you can open it and you can see what is inside this thing and verify that your nonce is over here. So, this is one part of the message and the rest is the session key A A B that A is able to decrypt and the identity of B and also this R 3. So, this R 3 was sent over here now the KDC says you want this way you will believe that I am really the KDC because I am including the this R 3 which you sent in the clear I am including that nonce over here and I am encrypting it with a long term secret that we share. So, now you will be convinced will only I can either KDC can encrypt this R 3. So, you decrypt it and verify that you get back R 3 the thing that you sent over here and then the rest of the protocol is like what we have seen before the mutual authentication. So, this is hopefully the corrected version of the medium shorter protocol extra nonces and so on, but those are just to guarantee the freshness of these messages. So, that you can you are not vulnerable to a replay attack or a man in the middle attack ok. So, another protocol that is widely used and that has been inspired by medium shorter is the Kerberos protocol. So, let us look at the wish list for Kerberos first and foremost you have something like a campus a network with multiple users and multiple servers in an organization such as a university campus. A user once logged in may wish to access. So, I log in just once I do not want to mess with this password thing again and again and again. So, I log in just once with my password I wish to access different resources such as an email server file server etcetera in the course of that login session. One possibilities for the user to have multiple passwords on each of these servers because I want to access each of these servers. So, a separate password for each server, but that is a big hassle. However, having humans remember an update multiple passwords is not very practical. Now, a user could use the same password for all the servers. So, the same password for this server and this server and so on, but distributing and maintaining a password file across multiple servers is a security hazard. So, I do not want to do this either. So, can I think of something smart. Then as far as the password is concerned the password should not be transmitted in the clear because anybody can eavesdrop on it. It should not be possible to launch dictionary attacks using the eavesdropped upon messages containing a function of the password. So, if I have got the hash of the password in the communication if I get that I can launch a dictionary attack and possibly get the password out. So, so many different considerations. The password itself should not be stored on the authentication server rather it should be cryptographically transformed before being stored. It should not be possible to launch dictionary attacks by obtaining a file containing the cryptographically transformed password. So, you can have you can have dictionary attacks on the password file, you can have dictionary attacks on messages that contain the password or a function of the password. So, we have to be careful about all of these things. So, what is the final solution to this? Okay, besides that there are just a little bit more. A user enters a password only once during login. So, I mentioned this before. Thereafter she should not have to reenter her password again and again to different for to access different servers. So, this feature is commonly referred to as single sign on. The other thing is when I enter my password I do not want it to be there for the next half an hour because they could be attacks on the RAM and so on and so forth. All sorts of stealth attacks. So, the password should reside on a machine for only a few milliseconds after it has been entered by the user. Thereafter all vestiges of the password even if I am logged in for the next five hours that password or anything related that password should not be there on that machine. So, thereafter all vestiges of the password should be destroyed and image of the password should not linger on in either volatile or non-volatile memory of the machine. So, one solution to this is Kerberos. Again this has gone through many many different versions. So, this is a widely used protocol supported on several operating systems including Bista and Microsoft Server 2008. The key distribution center that we talked about before is actually split logically now into two parts logically not necessarily physically. It is split into two entities the first entity is called the authentication server or AS and the ticket granting server TGS. So, AS and TGS like before the ticket is the mechanism used to safely distribute session keys. So, I will authenticate myself to somebody get a session key and then use it for the duration of session. So, the same basic idea, but with a little bit more some more frills. So, some more details here. So, there are two kinds of entities in the system there are human beings who are users and there are servers who provide service. So, each human user A of the system shares a secret KA a long term secret which is typically a function of the password with the authentication server. So, once again the KDC key distribution center has been logically split. So, different functions for the AS and the TGS. So, the KDC is now split between the authentication server and the ticket granting server and each human user shares a secret that is a function of the password with the authentication server. This secret is essentially the hash of the user's password. Then each server B shares a secret KB with the TGS not now the AS, but the ticket granting server unlike the Needham Schroder protocol Kerberos makes use of timestamps. So, how this basically works is when you log in with your password the AS is involved in authenticating a user when she attempts to log in to the system. The AS then issues a ticket granting ticket to the user just keep this safely you have logged in I am giving you this one time ticket it is called a ticket granting ticket. Whenever you want a service granting ticket you should provide the you should produce the TGT produce to whom to the TGS. So, you have logged in to me your business is done you log in to me I will give you this TGT and do not bother me for the rest of this session. Now you start bothering the TGS every time you require different services. So, for each different server that needs to be accessed the client approaches the ticket granting server with the TGT that was obtained from the AS. The TGS first authenticates the user and then provides the user with a service granting ticket. So, it authenticates, but without the use of the password that is the beautiful part. So, the TGS authenticates the user and then provides the user with a service granting ticket to be handed over to the server whose service is required. Now the details of the messages are in the text in the interest of time I am not going to go through the detailed structure of each message what it contains and all the crypto stuff. So, you can see that for yourself, but basically these are the messages. There are total of six messages. So, the client over here the KDC which is logically split up into the authentication server and the ticket granting server and then this is your server which could be any generic server like a file server or a web server or whatever. So, the first step C request the ticket granting ticket. So, you produce your password some function of the password is used to create a message and then that thing is sent over here. It is verified and so on and if it verifies successfully then the AS produces a ticket granting ticket in this message and conveys it to the client. So, that is message number two C receives a ticket granting ticket from the AS the ticket granting ticket. Now the client continues its work at some point in time it needs the services of some server. So, what does it do? It goes to the TGS for that purpose. So, only a one time involvement or interaction with the AS and thereafter you might go again and again and again and again to this guy to request multiple services. So, for the first service that you require you go to this TGS request the service granting ticket you produce the ticket granting ticket to him. So, you produce the TGT the ticket granting ticket which was received in this message and you request for a service granting ticket SGT and a session key. So, you produce the TGT and request the service granting ticket SGT you get the SGT together with a session key and then it also produces a ticket which contains the session key for the server. So, that is then sent to the server and the standard mutual authentication between the client and the server you require fewer messages because you are using timestamps rather than nonces. So, this is basically how Kerberos works. So, with that more or less the actual details of these messages I think you should go through because they are very instructive and very interesting to see exactly how authentication takes place. So, the details of these messages are contained in the text and the chapter on medium showroom and it is actually security protocol part 2. So, this will happen at the end of the next session.