OTP Extended Responses
RFC 2243
Document | Type |
RFC - Proposed Standard
(November 1997; No errata)
Was draft-ietf-otp-ext (otp WG)
|
|
---|---|---|---|
Author | Craig Metz | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2243 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Sam Hartman | ||
Send notices to | <jered@mit.edu> |
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 Notice Copyright (C) The Internet Society (1997). All Rights Reserved. Abstract 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. Metz Standards Track [Page 1] RFC 2243 OTP Extended Responses November 1997 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. 2.1. Syntax In UNIX manual page like syntax, the general form of an extended challenge could be described as: <standard OTP challenge> ext[,<extension set id>[, ...]] And the general form of an extended response could be described as: <type-specifier>:<arg1>[:<arg2>[:...]] In augmented BNF syntax, the syntax of the general form of an extended challenge and an extended response is: extended-challenge = otp-challenge 1*LWSP-char capability-list (NL / *LWSP-char) otp-challenge = <a standard OTP challenge> capability-list = "ext" *("," extension-set-id) extension-set-id = *<any CHAR except LWSP, CTLs, or ","> extended-response = type 1*(":" argument) NL type = token argument = token token = 1*<any CHAR except ":" and CTLs> NL = <new line sequence appropriate for the context in which OTP is being used> Metz Standards Track [Page 2] RFC 2243 OTP Extended Responses November 1997 An example of an extended challenge indicating support for OTP extended responses and for a mythical response set "foo" is: otp-md5 123 mi1234 ext,foo An example of an extended response using a mythical type named "foo" is: foo:some data:some more data:12345 2.2. Requirements A server compliant with this specification: 1. MUST be able to receive and parse the general form of an extended response 2. MUST be able to receive, parse, and correctly process all extended responses specified in this document 3. MUST process the type field in a case-insensitive manner 4. MUST reject any authentication attempt using an extended response if it does not support that type of response 5. SHOULD provide an appropriate indication to the generatorShow full document text