[16923] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Fri Jun 17 14:15:04 2011
Message-Id: <201106171814.p5HIEfgV008558@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: dpal@redhat.com
In-Reply-To: <4DFB6B55.8090407@redhat.com>
Date: Fri, 17 Jun 2011 14:14:39 -0400
Cc: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>Providing a list of the valid OTPs to an external client would never be
>implemented by any vendor.
You are incorrect. I worked with one OTP vendor who did exactly that,
and we deployed that solution with Kerberos (and we're not the only ones).
Now, I will agree that a large company like RSA is never going to
do that, because they don't have to; they have enough clients that
the people who want to use SecurID with Kerberos is a tiny part of
their customer base. But the competitors to SecurID may be more
open to anything that can give them some advantage over RSA; it's not
a guarantee, but it is a possibility.
>Exposing valid future OTPs to a remote party is very dangerous.
>How you are going to protect it?
>With what? Password, cert? Static key?
>This can be confined to a specific use case (potentially) but it is too
>costly and too risky to implement such interface.
Meh. This is a solvable problem; pick a solution that meets your security
requirements. For example, a static key would certainly be sufficient,
or you could co-locate your OTP server with your Kerberos server. When
I hear "it's too hard", to me that really means, "We don't want to bother".
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
