OTP Extended Responses
Extracted elements (22)
The 'hex' and 'word' response types solve an ambiguity problem: a standard OTP response could in rare cases be valid in both hexadecimal and six-word formats (e.g., 'ABE ACE ADA ADD BAD A'). The OTP spec requires servers to try both formats, but extended responses eliminate the ambiguity by making the encoding explicit.
The init-hex and init-word responses are intended primarily for automated clients, which is why the hexadecimal encoding is recommended: it is more machine-friendly. However, the protocol also permits manual user entry of these responses.
All init-hex response fields that carry OTP data MUST be hexadecimally coded, and all init-word response fields MUST be six-word coded. These responses MUST NOT span more than one line in actual use despite their length.
A generator MUST be able to generate standard OTP responses, MUST use standard responses unless an extended challenge has been received for the particular server AND seed, MUST generate the type field in lower case, and MUST NOT send a response type the server has not indicated support for.
A generator SHOULD warn the user if the sequence number falls below ten, MUST refuse to generate OTPs with a sequence number below one, and SHOULD NOT retry a failed re-initialization or perform re-initialization without the user's permission.
A server MUST be able to receive and parse the general form of an extended response, process all specified extended responses, treat the type field case-insensitively, and reject authentication attempts using unsupported response types.
A server MUST disable all OTP access to any principal whose sequence number would be less than one, and MUST decrement the sequence number if a reinitialization response includes a valid current-OTP but the server cannot process the new-params or new-OTP for any reason.
A server MUST limit the length of the input reasonably, MUST accept otherwise arbitrary amounts of whitespace wherever a response allows it, and MUST be able to receive and correctly process standard OTP responses.
A server processing 'hex' and 'word' responses MUST process all arguments in a case-insensitive manner. A generator SHOULD generate otp-word tokens in upper case with single spaces separating them, and SHOULD generate hexadecimal numbers using only lower case for letters.
A server SHOULD NOT allow a user to use the same value for their seed and secret pass phrase. A generator also SHOULD NOT allow this, and MUST take specific steps to prevent infinite loops of re-initialization attempts in case of failure.
Extension set identifiers and extension type identifiers named with the prefix 'x-' are reserved for private use. Implementations that do not recognize a particular 'x-' extension MUST ignore it. All remaining extension namespace is reserved to IANA.
Implementations that support OTP extended responses MUST support the 'init-hex' and 'init-word' response types, which provide a standard mechanism for a client to re-initialize its OTP sequence and change parameters including the secret pass phrase.
Upon successful re-initialization, a server MUST store the new OTP as the last successful OTP received, and the sequence number in the next challenge MUST be one less than the sequence number specified in the new-params field.
An extended challenge is a single line containing a standard OTP challenge, a whitespace character, and a capability list starting with 'ext' optionally followed by comma-separated extension set IDs. It signals to generators which extended responses the server supports.
The 'hex' response encodes a 64-bit OTP as 16 hexadecimal characters (with optional whitespace) prefixed by 'hex:'. The 'word' response encodes a 64-bit OTP as 6 OTP dictionary words prefixed by 'word:'. These explicitly identify the encoding to avoid ambiguity.
The new-params field contains algorithm (md4/md5/sha1), sequence-number (up to 4 digits), and seed (up to 16 alphanumeric characters). It is hashed as a string the same way a seed or secret pass phrase would be; other field values are hashed in uncoded binary form in network byte order.
A successful active attack on the re-initialization response is more severe than hijacking a single session: an attacker who substitutes their own new-OTP could use the OTP system to authenticate as the victim at will until detected.
Extended responses, like OTP itself, do not protect against active attacks. IPsec AH (RFC 1826) or another technique of equivalent strength SHOULD be used to protect against such attacks.
Failure to implement server requirement 3 of section 4.3 (decrement sequence number on failed re-initialization) opens an implementation to a replay attack using the current-OTP portion of the response.
An extended response is a single line of printable text containing two or more colon-separated tokens. The first token is the type specifier; subsequent tokens are argument data. At least one argument token MUST be present.
The hex-response format is 'hex:' followed by hex-64bit (16 hex characters with optional whitespace interspersed) and a newline. The word-response format is 'word:' followed by word-64bit (6 OTP dictionary words each followed by whitespace) and a newline.
The init-hex response format is 'init-hex:<current-OTP>:<new-params>:<new-OTP>' where current-OTP and new-OTP are hex-64bit values and new-params is 'algorithm sequence-number seed' (e.g., 'md5 499 ke6118'). The init-word response uses word-64bit encoding for OTP fields.