NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
Neil Haller <nmh@bellcore.com>
Ran Atkinson <rja@home.net>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-otp@bellcore.com
To Subscribe: ietf-otp-request@bellcore.com
Archive: ftp://ftp.bellcore.com/pub/ietf-otp/archive
Description of Working Group:
One form of attack on computing systems connected to the Internet is eavesdropping on network connections to obtain login id's and passwords of legitimate users [RFC 1704]. Bellcore's S/KEY(TM) one-time password system was designed to counter this type of attack, called a replay attack [RFC 1760]. Several one-time password implementations compatible with Bellcore's S/KEY (TM) system exist. These implementations are increasingly widely deployed in the Internet to protect against passive attacks.
The object of this working group is to write a standards track RFC for one-time password technology, using the technology in the Bellcore S/KEY system and related interoperable packages (e.g., logdaemon, NRL OPIE) as the basis for the group's effort. The standards-track RFC will enhance multi-vendor interoperability in one-time password authentication technologies and thereby help reduce security risks in the Internet.
General authentication servers are outside the scope of this working group. The ``S/Key-0'' system being considered for use in Kerberos is outside the scope of this working group.
The standards-track specification will describe how this one-time password technology can be used with at least the MD4, MD5, and SHA algorithms. The standard one-time password dictionary from RFC 1760 will be reused in order to maintain backwards compatibility with the various deployed systems, however, support for hexadecimal format passwords will also be mandatory to implement. The standard might specify passphrase quality checks for the secret passphrase. The standard will be specified so as to eliminate any possible conflict with the Bellcore trademark on the term ``S/Key.''
An Informational RFC might also be issued that describes conventions for the UNIX commands relating to one-time passwords, including command(s) to securely update a remote one-time password.
Goals and Milestones:
Done |
|
Reach agreement on required and optional attributes. |
Done |
|
Produce Internet-Draft specifying the IETF one-time password authentication technology. |
Done |
|
Final review (Working Group Last Call) of the Internet-Draft. |
Done |
|
Submit One-Time Password document to IESG for consideration as a Proposed Standard. |
Aug 96 |
|
Submit Internet-Draft on optional extensions to OTP. |
Dec 96 |
|
Submit Internet-Draft on OTP optional Extensions to IESG for consideration of publication as an RFC. |
Internet-Drafts:
· OTP Verification Examples
Request For Comments:
RFC |
Status |
Title |
RFC2243 |
PS |
OTP Extended Responses |
RFC2289 |
DS |
A One-Time Password System |
Minutes of the One-Time Password Authentication (otp) Working Group
Co-chairs: Neil Haller (Bellcore)
Ran Atkinson (cisco)
Reported by: Richard Graveman and Neil Haller
Mailing List Information:
General Interest: ietf-otp@bellcore.com
[Un]subscribe: ietf-otp-request@bellcore.com
Archive: ftp.bellcore.com:/pub/ietf-otp/archive
I. Status of WG Documents
The first item on the agenda was a brief review of the status of the working group's documents. RFC 2289, the base document that describes the protocol and replaces RFC 1938, is now Draft Standard. It includes the verification examples that were previously in <draft-ietf-otp-ver-00.txt>. RFC 2243 on OTP Extended Responses is now a Proposed Standard.
II. OTP in SASL
Chris Newman presented <draft-newman-sasl-otp-00>, which describes a proposal for integration of OTP into SASL. In SASL (RFC 2222), the client asks for a capability (service) and gets back a list of authentication mechanisms the server supports. The client then picks a mechanism, say Kerberos. Strings are exchanged until the authentication succeeds or is rejected. This proposal will allow OTP to be used with SASL based services such as IMAP, POP, LDAP, possibly SMTP, and so forth. The draft currently adds two SASL mechanisms, OTP-MD5, and OTP-SHA1, based on the different OTP hash functions. Three approaches to handling the existence of multiple OTP hash functions were presented. The first, as above, is to make OTP into two distinct SASL mechanisms, the second is to require implementation of both MD5 and SHA-1, and the third (a variation of the second) is to make one method the preferred one. The question comes down to whether the algorithm name is in the SASL mechanism name or merely in the OTP challenge, which would consist of hash function, seed, and sequence number. If the algorithm is not part of the SASL mechanism, it is easier to support separate generators or pre-generated passwords. It was also pointed out that a server may support MD5 for some clients and SHA-1 for others, but may not know who the user is before authentication starts.
Consensus was that this work should be on the standards track. After some discussion, clear consensus also formed that SASL should not specify the algorithm, but just offer OTP as an option. Chris agreed to prepare a new draft to be issued as a working group document.
The working group recommended updating the charter to reflect this work item.
III. Documents
RFC 1760, N Haller, February 1995 Informational
RFC 1938, N Haller & C Metz, May 1996 Replaced by RFC 2289
draft-ietf-otp-ver-00.txt Absorbed in RFC 2289
draft-ietf-otp-ext-01.txt Replaced by RFC 2243
RFC 2243, C Metz, OTP Extended Responses Proposed standard
RFC 2289, N. Haller et al, A One-Time Draft standard
Password System
None Received
Roster Not Submitted