Authdata, preauth plugin headers

Dmitri Pal dpal at redhat.com
Mon Jun 13 11:17:46 EDT 2011


On 06/13/2011 10:47 AM, Linus Nordberg wrote:
> Sam Hartman <hartmans at MIT.EDU> wrote
> Fri, 10 Jun 2011 13:13:34 -0400:
>
> | Forc this protocol accepting replays is probably a bad idea.
>
> What kind of OTP systems are vulnerable to replay attacks?
>
> And what are the replay attacks?  Could it be something else than
> gaining a ticket, f.ex. desynchronising?  Do we have replay attacks on
> _parts_ of the chain that we have to protect against?
>
> The OTP preauth draft touches on the subject in section 6.4 but I think
> I'd need some more thoughts.
>
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
The usual reply attacks that I heard about in the past are about playing
same code against the replica or same server.
So here are couple scenarios:
1) I managed to intercept (overlook over your shoulder) your OTP and I
am playing it against a different server (replica) in parallel to the
first server handling your request.
2a) I managed to intercept (overlook over your shoulder) your OTP and I
am authenticating with the same server as you are but faster than you.
2b) I managed to intercept (overlook over your shoulder) your OTP and I
am authenticating with the same server as you are but but right after you.

But the solutions for those replay attacks are the responsibility of the
OTP server vendor.
The Authentication Manager has a solution called Adjudicator (in the
past Lock Manager). This is a service that keeps all the AMs connected
and implements a fast protocol to lock the token and interval being
authenticated. So as the server receives a requests it broadcasts to all
other servers that it is going to authenticate the token. If other
servers see the same token being used they will reject it as the lock
will be present. There is a tricky logic to avoid race conditions.

For the cases 2a & 2b the Authentication Manager keeps the request in
its internal queue for (by default, configurable) 2 seconds and matches
the incoming requests to prevent the reuse of the OTP by someone else.
The reply is intentionally kept in the outgoing queue for these 2 second
to make sure that there is no other authentication happening.

After the authentication is done the last used interval/count is stored
in the database to make sure that no one can use it again.  
 
I am not sure if any of this should be done by KDC. IMO it is a pure
responsibility of the OTP server vendor.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the krbdev mailing list