OTP, deployability.

[Ken Hornstein]

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

Respectfully ... that is your opinion, and I don't agree.  Fine.
But it's at least something that _I_ can control and decide what
the appropriate security measures are.  One admitted weakness of
Kerberos is that the critical secrets have to exist _somewhere_
where the KDC can access them.  It's an obvious attack target.
However, it's a known problem and people have dealt with it.  It's
not generally considered a problem in practice.  I don't see why
an OTP server is any different.  And somehow I'm more comfortable
with a security model that depends on the security of the machines
I administrate, versus "the machines I administrate plus the machines
of some large corporation who doesn't really give a rat's ass about
me after they've made the sale" :-/

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

My point is that we shouldn't design protocols on the assumption that we
will never have access to the actual OTP token output.  As we have seen,
that assumption is false.  Obviously protocols should be designed so that
things will work in the case where the the token output is not available,
but if we can do better if the token output IS available then we should.

--Ken