[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Manual keying and replay prevention
On Fri, 4 Apr 1997, Bill Sommerfeld wrote:
> > Note that support for manual key distribution is required, but
> > its use is inconsistent with the anti-replay service, and thus a
> > compliant implementation must not negotiate this service in
> > conjunction with SAs that are manually keyed.
> >
> > Why not?
>
> The wording seems convoluted; as my impression was that manual keying
> implies that no negotiation takes place.
I assumed the negotiation takes place out of band (over the phone).
> I think the issue with manual keying and replay is recovery from a
> reboot.. unless you store the receive-side replay state in stable
> storage as each packet is processed, you can't allow the SA to survive
> a crash without running the risk that you'll accept a replayed packet.
This issue is no different from the case of a stream cipher like RC4. You have
to rekey after rebooting.
> (On the send side, you could checkpoint every N packets, and waste up
> to N packets of sequence space on a reboot. if you tried a similar
> hack on the receive side, you'd wind up needing to *ignore* up to N
> incoming in-sequence un-replayed packets..)
>
> Also, there's the issue of what to do when the replay counter maxes
> out..
Again as in the case of a stream cipher, the connection breaks and must be
rekeyed.
Norm
Norman Shulman Secure Computing Canada
Systems Developer Tel 1 416 813 2075
norm@border.com Fax 1 416 813 2001
References: