Re: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI
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
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
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
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
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
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
[Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI
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. -- 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
