Re: Ipsec encryption key when using digital certs

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.

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').

What you mentioned above is only true in a TLS-like encryption - which is
more of a shared key *exchange*.

Sadiq

On Sun, Apr 15, 2012 at 7:05 PM, Carlos G Mendioroz <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>> 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
>> >>
>>
>>
>> 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>>> 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>>> LW7
>> EQI Argentina
>>
>>
>> --
>> Carlos G Mendioroz <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>
>> >
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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