Is that your list or it is taken from some doc? The peers exchange their Public Certificate with MSG#5 and MSG#6, right? This certificate is then used for decryption of Hash sent in the same message. The router must calculate it's own hash and compare it with the hash received. If they are the same, the authentication is successful. Along with that, the Pub Certificate sent by the peer should be verified by CA certificate, CRL and clock (time and date).
Regards, Piotr 2011/1/19 Kingsley Charles <[email protected]> > Piotr > > I am still not clear, the usage of the sender's public key. Please modify > the following steps of Digital authentication process. > I am trying to find out where is the sender's public key should be > inserted. > > > 1. The IPSec peer downloads the CA certificate which consists the CA > Server public Key and verifies the CA Server. > 2. The IPsec peer sends the certificate request in PKCS#10. > 3. Sends back a X.509 certificate along with a signature and the peer's > public key. The signature is a hash of the peer's public key and other > values in request after which it is encrypted using CA's private key. > 4. The peer get's it's certificate from the CA server. > 5. During IPSec negotiation, the peer sends it's certificate to the > remote peer. The remote peer using the CA's public key from the CA > certificate is used to decrypt the signature. Both the peer should have > enrolled with same CA. > 6. Remote peer get's the hash value after decryption using CA pub key. > 7. The remote peer generates hash from the details and pulic key, it > got from the peer and compares the hash. > 8. If they are the same, then authentication succeeds. The same is done > vice-versa to authenticate the remote peer. > > > > With regards > Kings > > > On Wed, Jan 19, 2011 at 3:52 PM, Piotr Matusiak <[email protected]> wrote: > >> 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
