OTP, deployability.

[Ken Hornstein]

>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