OTP, deployability.

[Dmitri Pal]

On 06/17/2011 02:14 PM, Ken Hornstein wrote:
>> 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
It is not too hard. It is risky.
IMO it is a bad security practice to expose the OTPs in an interface.
Such interface would definitely become an attack target. Ant it is much
easier to attack than the recent attacks against RSA.


Yes the problem is solvable however someone needs to share the critical
credential information. It is either the KDC to the OTP server or OTP
server to KDC. You generally can't assume that they are on the same box
so there should be a protocol to share the info or better to create an
exchange sequence that would allow for information not to leave the
authenticating party or at least to leave in a such a form that it can't
be used for the authentication. This can be done but that would be a
very long shot. It would require standards work. And may be we should
think about this so that we can have a standard way of exchanging info
with an open source HOTP/TOTP server.

But it does not help much the original problem risen in this thread...

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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