Security impact of removing timestamp check in rd_rep()

[Andrew Bartlett]

On Mon, 2005-05-16 at 01:06 -0400, Sam Hartman wrote:
> >>>>> "Andrew" == Andrew Bartlett <abartlet at samba.org> writes:
> 
>     Andrew> On Sun, 2005-05-15 at 17:04 -0400, Sam Hartman wrote:
>     >> >>>>> "Luke" == Luke Howard <lukeh at PADL.COM> writes:
>     >> 
>     Luke> You actually want to check that they are different, to avoid
>     Luke> replay attacks.
>     >>  But you need to store all the timestamps you have seen in an
>     >> allowable window.
>     >> 
>     >> Really, I don't understand why you use a timestamp in a
>     >> three-leg protocol.  It seems like you want to have a challenge
>     >> in the second leg copied back in the third leg encrypted in a
>     >> per-session key.  However it sounds like DCE did not do this.
> 
>     Andrew> I think the sequence number is used for this.  It appears
>     Andrew> from the way Microsoft implements their server, that they
>     Andrew> don't check the timestamps.
> 
> OK, if sequence numbers are used, then timestamps probably should not be.
> 
> Well, it sort of has to be a DCE style third leg: krb5 does not
> normally have a third leg at all.

I've been thinking about this, and would like a reality check:

If krb5 had included this originally (assume it was mandatory), this
would have eliminated the need for the reply cache, right?  

My thinking is that an interceptor would not have access to the key
material, so could not produce the 3rd leg, and therefore could never
perform a reply attack?

Am I missing something?  (Aside from the lack of ability to influence
history)

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050516/ab72b376/attachment.bin