[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error protocol
Bill Sommerfeld wrote:
>
> > a) not everyone knows how many times that host rebooted so far. So
> > the latest cert of birth should be included in every phase 1
> > negotiation.
>
> I said.. "in the negotiation of the IKE SA".. same thing.
yep, ok. I was mislead by the order of things in the sentence. My bad.
> BTW, from the embedded device front, my understanding is that SNMPv3
> security uses a reboot counter, so maintaining this shouldn't be a
> problem for the embedded folks.
>
> > b) if an attacker finds a way to reboot a host generating certs of
> > birth, this can force the signing host (either the host itself (self
> > signed cert)) or the CA to sign an enormous amount of data, therefor
> > weakening its private key (clear text attack). I do not know how
> > efficient that would be but I would welcome the advice of a
> > cryptographer.
>
> I used the term "certificate" in the generic sense. In some sense it
> could be more accurately described as a "death certificate for all
> prior state".
>
> It wouldn't have to be (and probably shouldn't be) in x.509
> format.. (x.509 specifies one way to do "certificates"; it is not the
> only way to do certificates, and in some cases, like this one, an
> application-specific format is appropriate).
Right but to make the notification (ICMP or whatever) accepted by the other side, you need to have the pseudo-cert signed by a form of pub key signature. The pub key must be assumed known everywhere => it can not be something negotiated (chicken & egg) => it would weaken the private key over time.
IKE, typically does not use the public keys directly (except in revised pubkey encryption but who uses it?) and I always assumed that we wanted to encrypt as little as possible with our pubkey. With digital signatures, this is done only after the DH exponentiation => the attacker would have to spend a considerable amount of CPU time to do that.
Frankly, these are just thoughts; I have no idea how this would be considered secure by crypto folks.
Oh yes... and here is the "flaw": you unveil the identity which is what Main mode tried to protect. Imho, not a big deal compared to the advantage.
In any case, your proposal is similar to mine then (I just did not notice). Except that I do not rely on a cert at all but I leave the burden on the one that misses the SA. However, this problem is embedded within IKE itself.
Summary:
your solution
-------------
-pro's: uses a cert of birth => notification is trustworthy. Deletes all the old SA's at once. Puts the burden of the one that thinks it has valid SA's.
-con's: Requires an extra packet anyway (notification). Requires the definition of a new type of cert (hard). May weaken the private key. Unveils normally hidden identities.
my solution
-----------
-neutral: just as strong/weak as IKE cookies
-con's: Requires a delete notification per SA to delete.
I think I can modify my solution to integrate your advantages by defining two new ISAKMP payload.
Scenario:
here, B is missing an SA to decapsulate traffic sent by IP(A)/SPI(xxx).
New payloads:
. "in order to delete SA with SPI xxx"
. "my reboot sequence number is yyy"
IP(B->A) UDP (500,500) CKi,0 | SA proposals | "in order to delete SA with SPI xxx"
IP(A->B) UDP (500,500) CKi,CKr | SA chosen | "in order to delete SA with SPI xxx"
IP(B->A) UDP (500,500) CKi,CKr | keying material
IP(A->B) UDP (500,500) CKi,CKr | keying material
IP(B->A) UDP (500,500) * CKi,CKr | sig(hash) | [regular CERT] | ["my reboot sequence number is yyy"]
IP(A->B) UDP (500,500) * CKi,CKr | sig(hash) | [regular CERT] | ["my reboot sequence number is zzz"]
. here, A would respond to B only if it actually had an outbound SA with SPI xxx.
. if "my reboot sequence number is yyy" is present and yyy > previous seq#, all phase 2 SA's with that identity are deleted (same with zzz (optional)).
. at the end of the exchange, A should delete SPI xxx.
. if B has additional SA's to delete (but not all), it can send *protected* delete notifications.
And now, you have exactly the same level of security as Main Mode at the (small) expense of defining two new payloads, without additional cryptography *at all* (not even certs of birth).
Correct me if I am wrong, it is a status quo for IKE (level of protection) but it fixes the missing phase 2 SA issue.
frederic
> - Bill
Follow-Ups:
References: