On Wed, Jun 06, 2007 at 11:58:38AM -0700, Henry B. Hotz wrote: > The OTP travels over a TBD link to the KDC. The KDC then uses the > vendor-provided software to validate the OTP; in other words the > vendor is validating that the KDC has a valid OTP.
How is that different than with, say, PAM? How can the OTP server know whether its client is a telnet server, or something else? How can it know that the user is on the client's console, logically or physically? > The OTP vendor never validates the client and has no connection to > the client. However that is exactly the problem which needs to be > solved. Right -- that's a problem with the OTP protocols that we have. Now I understand your issue. My argument is that to get better than this we'll need key generating OTPs. So we can build authentication mechanisms (for EAP/GSS/SASL, pre-auth for the Kerberos V KDC PDU exchanges, etc...) that can do better than today's simple minded just-send-the-OTP-over schemes. That's definitely way out of scope for this list, UNLESS we (including you) want to develop our own OTP protocols and authentication mechanisms here. But I suspect we don't. Nico --
