Re: Ipsec encryption key when using digital certs

Well, this whole thread is in the context of IPSec, as Ajay posed the first
email ;-). Not sure if your question has been answered within the rumble
here, Ajay?

Also, please pay attention to my careful use of 'key private and public
components' - and yes, DH in IPSec uses private vs public components of
some sort of generated numbers. This was not referring to RSA keys you
would generate on a Cisco IOS though.

On Sun, Apr 15, 2012 at 9:47 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Sadiq Yakasai @ 15/04/2012 17:06 -0300 dixit:
>
> Thanks for the information on the first point - ditto.
>>
>> On the second point, I'm not sure which is it here but you either did
>> not pay attention to what I said earlier or did not understanding it
>> altogether. But end of the day, we seem to be saying the same thing on
>> the second point.
>>
>> I repeat: a digital signature on a X.509 certificate is in fact
>> encrypted. Yes, I did not say the encryped information is hash and yes,
>> I did not state its used for authentication. That was implied and not
>> the focus of the point. Go back and read it again - you will see. My
>> statement did NOT refer to the act of encrypting information to achieve
>> confidentiality.
>>
>
> You are right, I jumped without reading it with enough detail.
> (Still, I would not say that the signature is encrypted; an encrypted hash
> makes a signature, but that's ok).
> I wanted to stress that the certificate per se was not encrypted.
>
> On your other point 'Once you know for sure the other endpoint public
>> key, you could just generate a random secret, cipher it with the public
>> key and send it in the clear. The only one able to descipher it would be
>> the intended endpoint (because it is the one holding the corresponding
>> provate key) and now both ends have a "shared key" to be used for
>> simetrical cipher.'
>>
>> I am afraid this is not exactly true in the case of IPSec, which uses DH
>> key */negotiation/* algorithm. The actual session key is never
>>
>> transmitted across the medium. The 2 parties involved exchange a key
>> pair's public component, and each party uses the other's public
>> component, in combination with its key private component to arrive at
>> the same session key (which you refered to as a 'shared key').
>>
>
> I was careful to say "you could just..." to describe what would be a sound
> protocol WRT security. I was not trying to describe the way IPSEC does it,
> cause there are many ways you can configure it.
>
> Now, DH does not involve public keys AFAIK. Yes, it uses the same large
> prime modulo properties, but that's it. And yes, the simetric (session) key
> does not travel accross the medium in any easily definable way.
> (muddy waters here WRT information theory :)
>
> What you mentioned above is only true in a TLS-like encryption - which
>> is more of a shared key */exchange/*.
>>
>> Sadiq
>>
>
> -Carlos
>
>
>>
>>
>> On Sun, Apr 15, 2012 at 7:05 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>> wrote:
>>
>> Sadiq Yakasai @ 15/04/2012 12:46 -0300 dixit:
>>
>> Carlos,
>>
>> I am not sure I agree with you on 'honoring a certificate from a
>> different CA, if you know its public key' in this context.
>>
>> How can you have multiple CA root certificates in a single
>> trustpoint on
>> a Cisco router? Unless I am missing something here. Under a single
>> trustpoint, you can have 2 certs right? A CA root cert and a
>> personal
>> one. If a router is authenticating ISAKMP using rsa-sig, then
>> you are
>> basically using one trustpoint, right?
>>
>>
>> You are missing something. One trustpoint corresponds to one CA.
>> But you can have multiple trustpoints defined in a router, and an ipsec
>> profile can use all of them to verify a certificate.
>> Quoting cisco:
>> If no trustpoint is specified in the ISAKMP profile, all the
>> trustpoints that are configured on the Cisco IOS router are used to
>> validate the certificate.
>>
>>
>> Also, can you explain more what you mean by ' Signed content is not
>> encrypted. A certificate is a public key and identity content,
>> signed.'?
>> AFAIK, a digital signature on an X.509 certificate is in fact
>> encrypted. No?
>>
>>
>> No.
>> Encryption is a tool that serves many purpouses, mainly
>> authentication and confidentiality (plus non-repudiation).
>> Confidentiality is the easy one to understand. There you have raw
>> content and encrypted content, and the latter you can't
>> understand/see/decode. Usually when someone says "that's encrypted",
>> he is referring to this function, i.e. confidentiality.
>>
>> Authentication is more involved, and is usually performed by signing.
>> Signing refers to encrypting a hash, which in turn refers to
>> functions that somehow condense key features of some content in a
>> smaller piece.
>> The hashing algorithms create a small (usually fixed length)
>> representation of whatever content you whant to protect. This algo
>> is public and we commonly use MD5 (128 bits hash) and SHA (160 bits
>> hash).
>> Good property of a hash is that is you change the "protected
>> content" then the hash changes, with high probability (But not
>> necesarilly).
>> In fact many documents do have the same hash, but it is
>> computationaly complex to create a document with any given hash, so
>> tampering with a hashed document is hard (but not imposible).
>>
>> So what the CA does is take your data (domain name, geographic data,
>> and public key plus some cert data like issue date and certificate
>> purpouse), creates a hash of all this and encrypts it. You receive
>> all the data (coded but not encrypted) plus the encrypted hash (AKA
>> the signature). You can recreate the hash on your own and compare
>> that with the one provided by the CA, decrypted by you. If both
>> agree, you have a high confidence that the certificate was not
>> tampered with and then, that this public key corresponds to the
>> identifying data (domain name ?) that it says, because you trust the
>> CA.
>>
>>
>>
>> Maybe you can explain more what you mean here and educate us
>> more please.
>>
>>
>> Please do let me know if this makes sense now.
>>
>>
>> Thanks!
>> Sadiq
>>
>>
>> -Carlos
>>
>>
>> On Sun, Apr 15, 2012 at 4:14 PM, Carlos G Mendioroz
>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>> wrote:
>>
>> I still don't like it :( But that's just me :)
>>
>> Hashes from different documents don't have to match. What has
>> to
>> match is the calculated hash by the sender and bey the
>> receiver,
>> where the sender one is protected by encryption.
>>
>> And by different CAs I was not referring to hierarchy. You can
>> honour a certificate from an altogether different CA if you
>> know its
>> public key.
>>
>> Signed content is not encrypted. A certificate is a public
>> key and
>> identity content, signed.
>>
>> -Carlos
>>
>> Brian McGahan @ 15/04/2012 09:28 -0300 dixit:
>>
>> > Brian,
>> I don't follow this step, and what you mean by
>> "authentication
>> strings".
>>
>> That's what the hash is. Its a string that has to match
>> for the
>> authentication to succeed.
>>
>> > In fact, it would follow from your explanation that both
>> endpoints
>>
>> should have certificates from the same CA, which is
>> not the
>> case.
>>
>>
>> Right, this would be the most simplistic case, where all
>> certs
>> come from
>> the same CA. Of course in a real design you can have
>> subordinate
>> CAs,
>> levels of hierarchy, cert chains, etc. but in the end
>> the logic
>> is still
>> the same that you decrypt what the CA signed with their
>> private
>> key by
>> using their public key, in order to find the
>> authentication string
>> inside (the hash).
>>
>> Brian McGahan, CCIE #8593 (R&S/SP/Security)
>> bmcgahan_at_INE.com <mailto:bmcgahan_at_INE.com
>> <mailto:bmcgahan_at_INE.com> <mailto:bmcgahan_at_INE.com
>>
>> <mailto:bmcgahan_at_INE.com>>>
>>
>>
>> Internetwork Expert, Inc.
>> http://www.INE.com
>>
>> On Apr 15, 2012, at 7:16 AM, "Carlos G Mendioroz"
>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>> wrote:
>>
>> Brian,
>> I don't follow this step, and what you mean by
>> "authentication strings".
>>
>> In fact, it would follow from your explanation that
>> both
>> endpoints
>> should have certificates from the same CA, which is
>> not the
>> case.
>>
>> The "key" to PKI is to understand that the identity
>> of one
>> entity is
>> conveined by the the knowledge of its public key. Once
>> I
>> know for sure
>> that a given public key is the one that corresponds
>> to an
>> entity (router
>> in this case), I can be sure (authenticate) any
>> material,
>> included that
>> used for generating shared keys to be used in
>> simetrical
>> ciphers.
>> But this is not trivial because some fake A' can
>> come and
>> say "this is
>> the public key for A" and then fool anyone. This is
>> also
>> true for CAs.
>> And there is no secure way of "knowing for sure" using
>> protocols alone.
>> You need and out of band warranty that you have a
>> common
>> trust point,
>> and that knowledge comes, usually, by comparing some
>> hash of the
>> certificate of the TP, usually a common CA.
>>
>> The process of validating a certificate is by hash
>> checking. The
>> certificate has a hash encrypted by the CA private
>> key. The
>> router can
>> recompute the hash and compare it to the decrypted hash
>> (that it can
>> decrypt because it has the other's router CA public
>> key).
>> This encrypted
>> hash is what we call a signature.
>>
>> Once you know for sure the other endpoint public
>> key, you
>> could just
>> generate a random secret, cipher it with the public
>> key and
>> send it in
>> the clear. The only one able to descipher it would
>> be the
>> intended
>> endpoint (because it is the one holding the
>> corresponding
>> provate key)
>> and now both ends have a "shared key" to be used for
>> simetrical cipher.
>>
>> The whole thing is that simetrical ciphers are *way*
>> cheaper to
>> implement, i.e. faster to crypt/uncrypt.
>>
>> Hope this helps.
>> -Carlos
>>
>>
>> Brian McGahan @ 14/04/2012 20:34 -0300 dixit:
>>
>> With CA based authentication, both you and I
>> generate
>> both public and
>> private keys,
>>
>> and then we then get the public key of the CA
>> server. Next
>> we both send
>> our public
>> keys to the CA server, who adds some authentication
>> strings
>> to them, and
>> then encrypts
>> them with the CA's private key. The result of this
>> is our signed
>> certificates.
>> Remember that something encrypted with a private key
>> can be
>> decrypted
>> with a public key.
>> This means that if I give you my certificate (which was
>> signed with the
>> private key of
>> the CA) you can decrypt it by using the CA's public
>> key, and
>> find the
>> authentication
>> strings that the CA added. You then decrypt your own
>> certificate with
>> the CA's public
>> key, get the authentication strings, and compare it
>> against
>> mine. If
>> these strings match
>> it means that both our certificates were signed by
>> the same
>> CA, and the
>> authentication is
>> successful.
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>> LW7
>>
>> EQI Argentina
>>
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>>> LW7
>> EQI Argentina
>>
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>>
>> ______________________________**______________________________**
>> ___________________
>>
>>
>> Subscription information may be found at:
>> http://www.groupstudy.com/____**list/CCIELab.html<http://www.groupstudy.com/____list/CCIELab.html>
>> <http://www.groupstudy.com/__**list/CCIELab.html<http://www.groupstudy.com/__list/CCIELab.html>
>> >
>>
>>
>> <http://www.groupstudy.com/__**list/CCIELab.html<http://www.groupstudy.com/__list/CCIELab.html>
>> <http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>> >>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> CCIEx2 (R&S|Sec) #19963
>>
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>> LW7
>> EQI Argentina
>>
>>
>>
>>
>> --
>> CCIEx2 (R&S|Sec) #19963
>>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>

-- 
CCIEx2 (R&S|Sec) #19963
Blogs and organic groups at http://www.ccie.net