Ajay,
There are three fundamental symmetric encryption keys generated during
Phase 1 (SKEYID_a, SKEYID_d, SKEYID_e), but they all are derived from
a value known as SKEYID. This value is calculated differently for
different authentication methods: pre-shared key, digital signatures
and public keys. Per the RFC:
- For digital signatures:
SKEYID = prf(Ni_b | Nr_b, g^xy)
- For public key encryption:
SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)
- For pre-shared keys:
SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
You may find the explanation of the notation/terminology in the
RFC2409 (e.g. g^xy is the DH secret), but what's important is that PSK
method builds SKEYID based on the 'pre-shared-key'. Why is there a
need to make pre-shared key part of SKEYID when we have the results of
DH exchange on hands, which is known only to initiator and receiver?
The reason is that with PSK authentication there is no "safe" method
to protect against Man-in-the-Middle attack without making the
pre-shared secret part of the encryption key. Let's say you decided to
just send the name/password for authentication (login), encrypting
them with DH-derived secret. Then, a party in between may have spoofed
two DH exchanges with "true" initiator/responder and intercept the
secret. To avoid this possiblity, authentication is "fused" with
encryption process, which rules out the middle party since it cannot
properly generate the encryption key.
All other authentication methods (signatures/pulic keys) do not need
that trick, as they use validation process, which is resistant to MitM
attacks. See RFC 2409 for more details on the machinery, but that's
the basic idea :)
So to answer your question - all authentication methods with exception
to PSK use the result of DH-exchange to generate the shared encryption
key (Just like Brian said) and perform authentication independently.
Only the PSK method fuses the pre-shared key with DH-secret to perform
authentication resistant to MitM attacks.
PS
It may appear that PSK's SKEYID is contructed without using
DH-exchange results per the output above, but it's not true - the DH
key is furhter used to geenerate SKEYID_a,d,e as following (g^xy is
the shared DH secret):
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
15 APRELQ 2012G. 15:11 POLXZOWATELX Sadiq Yakasai
<sadiqtanko_at_gmail.com> NAPISAL:
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
-- Petr Lapukhov, petr_at_INE.com CCIE #16379 (R&S/Security/SP/Voice) CCDE #20100007 Internetwork Expert, Inc. http://www.INE.com Toll Free: 877-224-8987 Outside US: 775-826-4344 Blogs and organic groups at http://www.ccie.netReceived on Sun Apr 15 2012 - 16:53:32 ART
This archive was generated by hypermail 2.2.0 : Tue May 01 2012 - 08:20:45 ART