Browse Prior Art Database

Telnet Authentication Option (RFC2941)

IP.com Disclosure Number: IPCOM000005134D
Original Publication Date: 2000-Sep-01
Included in the Prior Art Database: 2001-Aug-16
Document File: 16 page(s) / 33K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Ts'o: AUTHOR [+3]

Abstract

This document describes the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 11% of the total text.

Network Working Group T. Ts'o, Editor Request for Comments: 2941 VA Linux Systems Obsoletes: 1416 J. Altman Category: Standards Track Columbia University

September 2000

Telnet Authentication Option

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 (2000). All Rights Reserved.

Abstract

This document describes the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type.

This document updates a previous specification of the telnet authentication option, RFC 1416 [2], so that it can be used to securely enable the telnet encryption option [3].

1. Command Names and Codes

AUTHENTICATION 37

Authentication Commands IS 0 SEND 1 REPLY 2 NAME 3

Authentication Types NULL 0 KERBEROS_V4 1

Ts'o Altman Standards Track [Page 1]

RFC 2941 Telnet Authentication Option September 2000

KERBEROS_V5 2 SPX* 3 MINK* 4 SRP 5 RSA*[also used by SRA*] 6 SSL* 7 [unassigned] 8 [unassigned] 9 LOKI* 10 SSA* 11 KEA_SJ 12 KEA_SJ_INTEG 13 DSS 14 NTLM* 15

Authentication types followed by were never submitted to the IETF for consideration as an Internet standard.

Following historical practice, future authentication type numbers and authentication modifiers will be assigned by the IANA under a First Come First Served policy as outlined by RFC 2434 [4]. Despite the fact that authentication type numbers are allocated out of an 8-bit number space (as are most values in the telnet specification) it is not anticipated that the number space is or will become in danger of being exhausted. However, if this should become an issue, when over 50% of the number space becomes allocated, the IANA shall refer allocation requests to either the IESG or a designated expert for approval. IANA is instructed not to issue new suboption values without submission of documentation of their use.

Modifiers AUTH_WHO_MASK 1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TO_CLIENT 1

AUTH_HOW_MASK 2 AUTH_HOW_ONE_WAY 0 AUTH_HOW_MUTUAL 2

ENCRYPT_MASK 20 ENCRYPT_OFF 0 ENCRYPT_USING_TELOPT 4 ENCRYPT_AFTER_EXCHANGE 16 ENCRYPT_RESERVED 20

INI_CRED_FWD_MASK 8 INI_CRED_FWD_OFF 0

Ts'o Altman Standards Track [Page 2]

RFC 2941 Telnet Authentication Option September 2000

INI_CRED_FWD_ON 8

2. Command Meanings

This document makes reference to a "server" and a "client". For the purposes of this document, the "server" is the side of the connection that performed the passive TCP open (TCP ...