Kings, CA signs router's certificate and then this certificate is used to sign the Hash during IKE Phase 1. The CA public certificate must be present on the router to validate the peer's certificate sent in the MSG#5.
Is all clear now? Regards, Piotr 2011/1/19 Kingsley Charles <[email protected]> > Hi Piotr > > I totally agree with you and that is logic behind the digital signatures. > The sender sign's it will his/her private key and the receiver verifies with > the sender's public key. This is the case, where there is no CA server. For > instance, we can consider the self-signed certificate. The signature in self > -signed certificate is encrypted using the router's private key. > > > With CA which is a third party signs the signature not the sender. This CA > is trusted by both sender and receiver. Hence signature is encrypted by the > CA not by the sender when CA servers are used. > > > Snippets from > http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_pki_overview_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1027184 > > > After each entity enrolls in a PKI, every peer (also known as an end host) > in a PKI is granted a digital certificate that has been issued by a CA. When > peers must negotiate a secured communication session, they exchange digital > certificates. Based on the information in the certificate, a peer can > validate the identity of another peer and establish an encrypted session > with the public keys contained in the certificate. > > > *1. *The end host generates an RSA key pair. > > *2. *The end host generates a certificate request and forwards it to the > CA (or the RA, if applicable). > > *3. *The CA receives the certificate enrollment request, and, depending on > your network configuration, one of the following options occurs: > > *c. *Manual intervention is required to approve the request. > > *d. *The end host is configured to automatically request a certificate > from the CA. Thus, operator intervention is no longer required at the time > the enrollment request is sent to the CA server. > > *4. *After the request is approved, the CA signs the request with its > private key and returns the completed certificate to the end host. > > *5. *The end host writes the certificate to a storage area such as NVRAM. > > > > With regards > Kings > > > On Wed, Jan 19, 2011 at 2:33 PM, Piotr Matusiak <[email protected]> wrote: > >> Kings, >> >> Here's the excerpt from the book "Network Security Principles and >> Practices" by Saadat Malik >> >> >> ---- >> Signature Payload >> >> This payload contains the initiator's signature. In general, a signature >> is a known value encrypted with an individual's private key. A signature >> provides nonrepudiation, meaning that because data encrypted using a private >> key can only be decrypted using its corresponding public key, the sender of >> the data cannot back out of admitting that he or she sent the data. No one >> else but that person possesses the private key (corresponding to the public >> key) that was used to decrypt the data. Obviously, the assumption is that >> the data is known a priori to both the sender and the receiver. In the case >> of message 5, this information is indeed a combination of information that >> has either already been exchanged between the two parties or that has been >> generated based on exchanged information and is the same on both sides (for >> example, the SKEYID). >> >> *The hash that is encrypted using the private key is generated by hashing >> the accepted proposal and transform payloads along with certain other values >> * >> >> --- >> Regards, >> Piotr >> >> >> 2011/1/19 Kingsley Charles <[email protected]> >> >> Hi Piotr >>> >>> You referring to the hash signature that has been attached to the >>> certificate, right? The CA server encrypts this hash with it's private key >>> and during the IKE Phase 1 authentication, the signature is decrypted by the >>> CA server's public key. >>> >>> Can you please let me know, how and when is the hash encrypted using the >>> router's private key? >>> >>> Even I thought that way but I don't find any docs claiming that process. >>> >>> With regards >>> Kings >>> >>> >>> On Wed, Jan 19, 2011 at 1:43 AM, Piotr Matusiak <[email protected]> wrote: >>> >>>> 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
