On 09/16/2013 06:04 PM, Henry B. Hotz wrote:
> On Sep 14, 2013, at 10:25 AM, Simo Sorce <s...@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 <d...@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.h...@jpl.nasa.gov, or hbh...@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/



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to