Kings, In MSG#5 and MSG#6 two encryption happen. One is an encryption of a Hash_I and Hash_R respectively and another is an encryption of a whole message. The first encryption is done using router's Private Key and another is used using SKEYID_e. Also all QM messages are encrypted using SKEYID_e.
Regards, Piotr 2011/1/18 Kingsley Charles <[email protected]> > Snippet from > http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1338498,00.html > > Although the sender's private key isn't used for authentication, it is > required to decrypt the sender's message. Communication is only completed > when the initiation message is decrypted; this can only be done with the > private key, which only the user has access to. > > > The peer's private key are meant to encrypt messages. > > Does it mean that IKE Phase 1 MSG5, MSG6 and IKE Phase 2 messages are > encrypted and decrypted by the private and public key? Said with this, it > means skeyid_e will not be used for encrypted IKE Phase 1 MSG5, MSG6 and > IKE Phase 2 messages . > > > The following are three keys generated from the shared secret arrived from > DH exchange of IKE Phase 1 MSG 3 and 4 exchanges. > > SKEYID_e – For encrypting IKE messages > > SKEYID_a – For authenticating IKE messages > > SKEYID_d – Keying material used to generate encrypting and authenticating > key for IPSec > > With pre-shared authentication, the above three keys are used for sure. > > > > With regards > Kings > > > On Tue, Jan 18, 2011 at 2:59 PM, Kingsley Charles < > [email protected]> wrote: > >> Did some investigation. >> >> The certificate exchanged for authentication, is to claim that public key >> carried in the certificate is bounded to the information in certificate and >> belongs to device or person who sent it. >> >> So basically, we are trying to authenticate the peer's public key. >> >> After a certificate exchange, if you issue "sh crypto key pubkey-chain >> rsa" you can see the public key installed. >> >> Now the peers after a successful authentication using digital cert, has >> installed each other's public key. >> >> What are peers going to do with the public keys? There should something >> else why would it be implemented like that? >> >> http://www.pgpi.org/doc/pgpintro/ >> >> >> Guys I know this out of the scope but I am trying to understand the >> Digital cert authentication and have been working for quite a long time. >> >> Please hit me with your best shot. >> >> I am close but missing a small bit of the map to the treasure island :-) >> >> >> >> With regads >> Kings >> >> >> On Mon, Jan 17, 2011 at 5:30 PM, Kingsley Charles < >> [email protected]> wrote: >> >>> Hi all >>> >>> With digital certificate authentication between Party A and B trying to >>> establish an IPSec connection, the private and public keys are used which is >>> used as following >>> >>> CA server Private Key - Used to encrypted the hash (signature) attached >>> to the party's certificate. >>> CA server Public key - The IPSec peer decrypts the hash using CA public >>> Key which it got from the CA server's root cert. >>> Party A Private Key - The party A encrypts the hash using it's private >>> key >>> Party B Public Key - The Party sends it's public key to party B in the >>> certificate. Party B used the public key to decrypt the hash. >>> >>> Party B calculate the hash of the Party B certificate and compares it >>> with the hash received. If the hash matches, authentication is successful. >>> >>> The same happens vice versa to authenticate Party A >>> >>> Is my understanding on the private and public purpose is correct? >>> >>> I have been working this for a long time but not able to get the exact >>> picture. >>> >>> RFC 2409 is very user friendly readable version :-) >>> >>> >>> With regards >>> Kings >>> >> >> > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
