Options
IKE phases
Hello everyone, I am a little confused on what happens at each stage, if some could clarify for me, i would very much appreciate it.
From my standpoint this is what i got so far.
At Phase 1, there are two modes to be picked from, aggressive and main.. But in general, phase 1 is resonible for setting up the agreements and Security Associations. by exhaning policies, paramets, and diffie-helman keys. Also authetication of the peers happen at phase 1.
at phase 2, a secure channel has already been made, and the paramets have already been agreed upon, at phase 2 the peers encrypt their shared secret keys, and send them over the link. That way the communication can be encrypted by the symmetric keys ranging from 64-256 bits, instead of the Diffie-helman/RSA keys which can range from 512-15000 bits.
at phase 1.5, an additional layer of authenication can be performed here, by using Xauth, which authenitcates clients before they use the VPN secure channel.
IKE also can do many other features such as NAT transveral which adds another UDP header infront of the encrpyted ip header, and behind the visible new ip header.
It can also automatically detect dead links, with a hello time of 10 secs.
do i have all the above correct ?
where my confusion comes into play is that, in Main mode, IKE sends the policies first, then the responder accepts one of the policies, then the Diffie-helman keys are exchanged (private/public)
but if the keys are sent after the policies are sent, does the leave the policies open and unprotected. Couldnt an attacker use this to gain viable information. (I know sounds a little odd and impossible, but it could happen)
I guess it can be perfectly secure. huh ? I figure IKE would exchange keys first, then send the policies encrypted and have the other side decrypt it, but it would add alot of overhead, especially using the diffie-helman keys.
From my standpoint this is what i got so far.
At Phase 1, there are two modes to be picked from, aggressive and main.. But in general, phase 1 is resonible for setting up the agreements and Security Associations. by exhaning policies, paramets, and diffie-helman keys. Also authetication of the peers happen at phase 1.
at phase 2, a secure channel has already been made, and the paramets have already been agreed upon, at phase 2 the peers encrypt their shared secret keys, and send them over the link. That way the communication can be encrypted by the symmetric keys ranging from 64-256 bits, instead of the Diffie-helman/RSA keys which can range from 512-15000 bits.
at phase 1.5, an additional layer of authenication can be performed here, by using Xauth, which authenitcates clients before they use the VPN secure channel.
IKE also can do many other features such as NAT transveral which adds another UDP header infront of the encrpyted ip header, and behind the visible new ip header.
It can also automatically detect dead links, with a hello time of 10 secs.
do i have all the above correct ?
where my confusion comes into play is that, in Main mode, IKE sends the policies first, then the responder accepts one of the policies, then the Diffie-helman keys are exchanged (private/public)
but if the keys are sent after the policies are sent, does the leave the policies open and unprotected. Couldnt an attacker use this to gain viable information. (I know sounds a little odd and impossible, but it could happen)
I guess it can be perfectly secure. huh ? I figure IKE would exchange keys first, then send the policies encrypted and have the other side decrypt it, but it would add alot of overhead, especially using the diffie-helman keys.
NHSCA National All-American Wrestler 135lb
Comments
-
Options
networker050184
Mod Posts: 11,962 Mod
Sounds about right to me.
When the policies are exchanged there is no sensitive traffic sent so there is no security treat. How would the receiving end know how to decrypt the policies if they did not first agree upon an SA?An expert is a man who has made all the mistakes which can be made. -
Options
redwarrior
Member Posts: 285
The policies themselves don't have to be protected. This is just where the two ends agree on what kind of encryption they will use, what kind of session timeout, etc. It doesn't really matter much if someone else sees this, but the two need to be in agreement on these settings before they can exchange keys and send any more sensitive information. If they don't find a set of policies they can agreement, the first SA isn't made and nothing proceeds further.
At least that's my understanding.
CCNP Progress
ONT, ISCW, BCMSN - DONE
BSCI - In Progress
http://www.redwarriornet.com/ <--My Cisco Blog -
Options
lildeezul
Member Posts: 404
Thanks everyone for the clarification.How would the receiving end know how to decrypt the policies if they did not first agree upon an SA?
Yeah i see it now.. thanks!!
Next chapter = chapter 14... configuration of site-site vpns.
So far i like the ISCW... has been fun, with many new terms and technologies.NHSCA National All-American Wrestler 135lb -
Optionslildeezul
Member Posts: 404
One more question before i move on to the next chapter.
When we are talkin about encrpytion, the larger the key bit ( 128 bit, 256bit) the stronger it is, and more of an output.
however, when talkin about Hashing algorithms, its not the same ? !
Is it safe to say that the larger the bit, the more accurate the results are.. ex: Sha-1 will have a better chance to find out if the packet has been tampered with, better than md-5, becuase sha-1 fixes it at 160bit, while md5 only fixes at 128bit ?NHSCA National All-American Wrestler 135lb -
Options
dtlokee
Member Posts: 2,378 ■■■■□□□□□□
The larger the hashing algorithm output the smaller the collision space will be with the outputs. According to the RFCs (240[34]) the hash output is truncated to 96 bits before transmission. I am not sure if that is how Cisco does it when talking between 2 Cisco branded devices or not.The only easy day was yesterday! -
Options
gojericho0
Member Posts: 1,059 ■■■□□□□□□□
Larger bits normally help because it gives you more combinations for the key. The most important thing though is the encryption/hash algorithm. You want one that is pretty good a producing a unique result and does not have too many dups -
OptionsNetstudent
Member Posts: 1,693 ■■■□□□□□□□
There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
