Browse Prior Art Database

OTP Extended Responses (RFC2243)

IP.com Disclosure Number: IPCOM000002802D
Original Publication Date: 1997-Nov-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 8 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Metz: AUTHOR

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 text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 16% of the total text.

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.

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:

ext[,[, ....