[Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI

[Dmitri Pal]

On 09/16/2013 06:04 PM, Henry B. Hotz wrote:
> On Sep 14, 2013, at 10:25 AM, Simo Sorce <simo at redhat.com> wrote:
>
>> On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote:
>>> On Sep 13, 2013, at 11:38 AM, Dmitri Pal <dpal at redhat.com> wrote:
>>>
>>>>> , ipatokenotpalgorithm
>>>> Uses default TOTP we do not support more for now. In future it will be a
>>>> global policy I assume.
>>> This is just me, like the sig says.
>>>
>>> I would advocate for HOTP, with a bunch of special processing for
>>> token counter regression.
>>>
>>> If the token seed and current counter are stolen by a bad guy, and
>>> actually used, then at some point the bad guy or the real user are
>>> going to attempt an authentication using a value that's "old".  This
>>> presents an opportunity to detect that the theft took place.
>>>
>>> I regard this as a real, useful security feature which is not possible
>>> with time-based tokens, provided the verification infrastructure is
>>> set up to do the detection, and to take some action when the detection
>>> occurs.  If the theft is done by a smart-enough adversary, there may
>>> be nothing to prevent them from resynchronizing the legitimate copy of
>>> the soft-token when they use it, but it still seems like a worthwhile
>>> capability.  It would detect the most obvious token-theft scenarios.
>>>
>>> Obviously, this is out-of-scope for any of your current efforts, but I
>>> wanted to throw it in the mix for possible future work.
>> Henry,
>> Thanks a lot for bringing this up.
>>
>> I have to say that I never liked HOTP due to the burden it takes to
>> correctly manage them compared to TOTP and the hardest work around
>> synchronization. The worst part of it being the need to write AND
>> synchronize across the infrastructure at every authentication attempt
>> (replication). Something that could easily bring the whole
>> infrastructure to its knees at busy hours.
> I won't pretend that's not a big issue.  However if you want to prevent re-use of time-based tokens, then you have the same problem.
>
> RSA allows you to prevent re-use.  

RSA used Lock Manager (6.x) or Adjudicator (7.x).
The idea is the same: fast replication of the interval that the code
corresponds to. Other replicas have to check before trying to lock the
same interval. It scales more or less but very complex.

> However I've been told it doesn't scale well, performance wise.  In particular you can't distinguish an automatic retry (like kinit would do after 1 second), from a hostile re-use (steal token in transit and use it yourself before it expires).

We changed the kerberos client library to have longer retries.

>
> I've also been told by people who did it that if you wanted to actually deploy the old SAM protocol you realistically had to configure RSA to allow re-use.  Otherwise the client might retry before the first response arrived, and all subsequent responses would be failures.
Yes so we fixed the kerberos client to not retry that quickly in TCP
case. This patch was submitted last spring.

> Substituting FAST/OTP for SAM doesn't change anything in the back-end exchange and performance. 
I do not remember the details of the patch described above, i.e. was it
generic or for OTP case only.

>  Someone commented that using TCP instead of UDP was useful for exactly those reasons, and that wasn't available back then.

Now it is.

>
>> However HOTP has obvious advantages when it comes to identifying attack
>> attempts, so I'll start thinking hard how to deal with it wrt
>> performance.
>>
>> Simo.
>
> There seems to be some interest in dealing with it in Heimdal.  I'd like to build the OTP service directly into the kdc so you can use {H,T}OTP directly with the old timestamp or FAST/encrypted challenge, but I seem to be a serious minority on this point.  
>
> If you export the OTP processing, then you export the performance/synchronization issues.
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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