[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ipsec error protocol

Hi,

My comments on the suggestions

1. Extending IKE (with new payloads etc) to what is basically an ipsec
problem seems to be an incorrect.
   If ipsec state (ipsec-SA) is out of sync between two peers, it should be
dealt in ipsec.

2. If IKE state(phase1 SA or phase2 SA) is out of sync between two peers, it
should be dealt as part
   ike protocol

Combining the two seems incorrect.

For example if a host has no ipsec-state for a communicating peer and wants
to convey that information,
it should not have to start another ike exchange for that purpose as
suggested. For all purposes
the host may not be interested in sending a udp[500] traffic.

Also the proposed solutions assume IKE and do not take of manual ipsec SAs.


-----Original Message-----
From: root@strange-brew.cisco.com [mailto:root@strange-brew.cisco.com]On
Behalf Of Frédéric Detienne
Sent: Wednesday, January 17, 2001 3:08 PM
To: sommerfeld@east.sun.com
Cc: Scott G. Kelly; sankar ramamoorthi; ipsec@lists.tislabs.com
Subject: 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 tw
o 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: