[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH/ESP / Replay Protection
At 16:53 22.12.95 -0800, Ran Atkinson wrote:
>AH/ESP most certainly does support session keys (aka traffic keys) by using
>multiple Security Associations. AH/ESP also support multiple namespaces.
Agreed. The problem was that I was comparing SKIP against AH/ESP, should
have compared it against Photuris. AH/ESP certainly allows for session keys.
But only Photuris (and SKIP) realize them. Point taken.
>Playback protection is a matter for the transforms at present, though that
>could be changed before Draft Standard IFF the WG wants to make that change
>and a specific proposal were made.
What about having a separate 'Replay Protection Header/Protocol' as suggested
by different persons? Or does everybody agree that replay protection makes only
sense if authentication via an AH or a (combined) authenticating ESP transform
takes place? In one case we have a new header and protocol type, in the
other case
we have keyed MD5, nested MD5, SHA, ... and all these with replay protection
added
-> a multitude of transforms. What would be preferable?
>The playback protection in SKIP is IMHO not worth what it costs to implement
>(i.e. its VERY low rent protection at present and not that hard to defeat).
It is defeated if you can change clocks in a radical manner. But in that
case, as
already pointed out somewhere, any system using key lifetimes and other
timing information is in danger. (btw, the cost to implement the hourly 'n'
is rather small.
And I sure can tell ;-) ) At the moment it seems better to me to have 'n'
and a 3 hour
granularity, than a granularity of up to [lifetime of top-level shared secret in
Photuris, on a system with a large amount of traffic] (meaning the 'knobs'
are turned
towards 'performance' and not 'maximum security'). I am not sure how long a
shared
secrect may be kept valid...
Sure, a dedicated mechanism for replay protection would be better.
Merry Christmas and a happy new year to you all!
Germano