OTP Implementation Report Here is the Implementation Report put together by Neil Haller (co-chair OTP) for consideration of draft-ietf-otp-02.txt for Draft Standard. Included below is information about four OTP (One-time passwords) implementation in support of the requirement for independent, interoperable implementations before a protocol can be accepted as a Draft Standard. The list is only a partial list of available implementations; it includes only those that were represented at a bake-off held December 10, 1996, in San Jose, CA. Name of implementation: S/KEY Name of implementation: OTP Name of implementation: OTP Toolkit Name of implementation: OTP During IETF on December 9th at 6pm, several folks gathered in the Terminal Room for an OTP interoperability demonstration. That demo combined with this email note is intended to fulfill the interoperability requirements for advancement of the OTP specification with the alternate dictionary feature being retained. Attendees were: Phil Servita, Neil Haller, Craig Metz, Ron Lee, and Chris Winters The "OTP Alternate Dictionary" implementations by Phil Servita and by Corwin (2 independent implementations) were interoperability tested successfully using MD4 and then again successfully using MD5. These tests used one implementation as client with the other as server, then reversed roles using the one implementation as server and the other as client. Corwin was unable to attend IETF, so he had setup both client and server that were accessible via the Internet for use in testing his implementation. Neil Haller verified that when incorrect responses were offered to each server, the server would in fact fail as appropriate (thus ensuring the servers were not "rigged" in some manner). At the same gathering, the (separate) "OTP Extended Responses" feature was tested with MD5 and {hex, word} for both "init" and "non-init" cases between the Phil Servita and Craig Metz ("OPIE") implementations. Although this last test is not strictly required at this time, it is mentioned for completeness. - Ran rja@inet.org |
|