OTP Extended Responses (RFC2243)
Original Publication Date: 1997-Nov-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented.
Network Working Group C. Metz
Request for Comments: 2243 The Inner Net
Category: Standards Track November 1997
OTP Extended Responses
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document provides a specification for a type of response to an
OTP [RFC 1938] challenge that carries explicit indication of the
response's encoding. Codings for the two mandatory OTP data formats
using this new type of response are presented.
This document also provides a specification for a response that
allows an OTP generator to request that a server re-initialize a
sequence and change parameters such as the secret pass phrase.
1. Conventions, Terms, and Notation
This document specifies the data formats and software behaviors
needed to use OTP extended responses. The data formats are described
three ways: using an ad-hoc UNIX manual page style syntax, using
augmented BNF described in sections two and three of RFC 822, and by
examples. Should there be any conflict between these descriptions,
the augmented BNF takes precedence. The software behaviors are
described in words, and specific behavior compliance requirements are
itemized using the requirements terminology (specifically, the words
MUST, SHOULD, and MAY) defined in RFC 2119.
2. Extended Challenges and Extended Responses
This document builds on the protocol and terminology specified in RFC
1938 and assumes that you have already read this document and
understand its contents.
An extended challenge is a single line of printable text terminated
by either a new line sequence appropriate for the context of its use
(e.g., ASCII CR followed by ASCII LF) or a whitespace character. It
contains a standard OTP challenge, a whitespace character, and a list
that generators use to determine which extended responses are
supported by a server.
An extended response is a single line of printable text terminated by
a new line sequence appropriate for the context of its use. It
contains two or more tokens that are separated with a single colon
(':') character. The first token contains a type specifier that
indicates the format of the rest of the response. The tokens that
follow are argument data for the OTP extended response. At least one
token of data MUST be present.
In UNIX manual page like syntax, the general form of an extended
challenge could be described as: