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

2013-09-17 Thread Henry B. Hotz
Thanks for the update.  Obviously my info is old, though I have seen issues 
with our RSA deployment that suggest things haven't effectively changed much in 
their product.

On Sep 16, 2013, at 7:44 PM, Dmitri Pal d...@redhat.com wrote:

 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.

The SAM client code was in MIT since sometime before 1.2.  They never added the 
server side, though I think they deployed a local version sometime a few years 
ago.

The server code was available IIRC as part of MRL's monster patch.  Only 
deployed by a few supercomputing sites.

--
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


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


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

2013-09-16 Thread Henry B. Hotz

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.  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).

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.

Substituting FAST/OTP for SAM doesn't change anything in the back-end exchange 
and performance.  Someone commented that using TCP instead of UDP was useful 
for exactly those reasons, and that wasn't available back then.

 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


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


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

2013-09-16 Thread Henry B. Hotz

On Sep 15, 2013, at 11:17 AM, Dmitri Pal d...@redhat.com wrote:

 On 09/13/2013 06:06 PM, 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.
 
 Count creates an overhead in the replicated environment. Effectively you
 need to replicate count on every authentication, this is a big cost.
 While it is more secure for the case you suggest it does not seem to be
 a good enough justification for the replication overhead. If stolen the
 chance that it will be used some tine later is really slim. It most
 likely will be used right away so the old code detection will be
 irrelevant. But we anticipate that there will be cases when HOTP will be
 needed, so we do not preclude implementing it in future but on the other
 hand do not see it as an immediate goal either.

If the bad guy uses the stolen seed immediately, yes it works.  However it 
advances the service's counter so the legitimate user will trip the monitor 
whenever he/she next uses the token.  

In other words the monitor will tell you of a problem, but it won't tell you if 
the user that demonstrated the problem was the good guy or the bad guy.  It 
also won't help if the good guy never uses the token at all after the theft.

--
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


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


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

2013-09-16 Thread Dmitri Pal
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


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

2013-09-15 Thread Dmitri Pal
On 09/13/2013 06:06 PM, 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.

Count creates an overhead in the replicated environment. Effectively you
need to replicate count on every authentication, this is a big cost.
While it is more secure for the case you suggest it does not seem to be
a good enough justification for the replication overhead. If stolen the
chance that it will be used some tine later is really slim. It most
likely will be used right away so the old code detection will be
irrelevant. But we anticipate that there will be cases when HOTP will be
needed, so we do not preclude implementing it in future but on the other
hand do not see it as an immediate goal either.


 --
 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


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

2013-09-14 Thread Simo Sorce
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.

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.

-- 
Simo Sorce * Red Hat, Inc * New York

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