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
