wdiff draft-newman-telnet-sasl-00.txt draft-newman-telnet-sasl-01.txt

Network Working Group C. Newman
Internet Draft: Using SASL/GSSAPI with Telnet SASL Option Innosoft
Document: draft-newman-telnet-sasl-00.txt January draft-newman-telnet-sasl-01.txt November 1998

Using SASL and GSSAPI with

Telnet SASL Option

Status of this memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).

Introduction

Telnet has its own custom authentication negotiation framework
defined in ''Telnet Authentication Option'' [TELNET-AUTH]. This has
primarily been used for Kerberos v4 [TELNET-KRB], but is largely
unused otherwise as there is only limited development of telnet
products and protocols.

Abstract

It is desirable to have telnet leverage
development of new security services common today for new Internet client software to implement
multiple Internet protocols. Therefore,
future use of the Telnet authentication option is deprecated in
favor of a new SASL [SASL] provides an
authentication option suitable for use
with SASL framework which permits multi-protocol clients and GSSAPI [GSSAPI] mechanisms.
servers to reuse security-sensitive authentication code. This service can
complement use of TLS with memo
defines a SASL profile for the Telnet [TELNET-TLS].

[NOTE: [TELNET] protocol.

This proposal is in response to a request by the TN3270e WG
to have SASL or GSSAPI available when TLS is too heavy-weight. I will not request a telnet option number for this until there is
rough concensus that it is a good idea. Public discussion of this
mechanism may take place be discussed on the tn3270e@list.nih.gov telnet-ietf mailing list
with a subscription address of listserv@list.nih.gov. Private
comments may be sent to list.
To subscribe, send the author]. word "subscribe" to
<telnet-ietf-request@bsdi.com>.

1. Conventions Used in this Document

The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].

Formal syntax is defined using ABNF [ABNF].

In examples, "C:" and "S:" indicate lines data sent by the client (end
which does a TCP active option) and server (end which does a TCP
passive open) respectively.

2. Mechanism Requirements

It is important that all telnet implementations are capable of
interoperable Background for this Proposal

Telnet has its own single-protocol authentication without the use of unencrypted
plaintext passwords.

For the usage scenarios with the TN3270 protocol, it looks like the
TLS protocol framework defined
in combination with traditional embedded plaintext
passwords will be preferable because TN3270 is often performed by a
proxy with no knowledge of the users. "Telnet Authentication Option" [TELNET-AUTH] which predates SASL
[SASL]. This suggests it is the
correct mandatory to implement mechanism for TN3270. Regular
telnet servers, on the other hand, have been successfully modified
to support mechanisms such as Kerberos, old Telnet authentication option and a full TLS layer might
be more expensive than necessary in many cases. This is where a
lighter-weight SASL or GSSAPI mechanism may be preferable.

Unfortunately, the CRAM-MD5 [CRAM-MD5] SASL mechanism (which is
likely associated
encryption option [TELNET-ENC] do not provide integrity protection
facilities, machine parsible error codes (e.g. to be alert the mandatory to implement choice for a number client
of
services) is particularly unsuited to the Telnet protocol as an expired passphrase), or a
machine which supports both CRAM-MD5 way to integrate GSSAPI [GSSAPI]
into Telnet.

Adding SASL and remote login risks
exposing the using it for new authentication database and thus risks an attacker
gaining the ability to impersonate all users mechanisms will
improve reuse of security-sensitive code in multi-protocol clients
in addition to any CRAM-MD5
authenticated service with addressing the same passphrase.

The SCRAM-MD5 [SCRAM] mechanism might suffice, but is probably too
new other issues. While it would be
possible to gain rough concensus. This leaves OTP-SHA1 [OTP-SASL] as
the preferred choice for layer SASL support on top of the mandatory to implement lightweight existing
authentication mechanism option, it could result in combination an extra round-trip and
would have potentially confusing interactions with this telnet extension.

[NOTE: This issue is certainly open for debate, as is the wisdom of
replacing modifiers
field in the old telnet AUTHENTICATE option]. Telnet authentication option.

3. Kerberos V4 Compatibility

Both SASL and the old Telnet authentication option offer Kerberos
V4 mechanisms. It is usually not desirable to deploy two
incompatible mechanisms for the same function, however, the
KERBEROS_V4 SASL mechanism is more resistant to reply attacks and
provides encryption integrity services. Currently deployed Kerberos V4
telnet Telnet
implementations use encryption support which was documented
in an expired internet draft have no integrity protection and the encryption
service is susceptible subject to an active attacks. down negotiation attack.

Implementations which offer support for the KERBEROS_V4 SASL
mechanism SHOULD also implement the old Telnet authentication
option Kerberos v4 mechanism. This will provide better
interoperability with deployed implementations. When both options
are available, the KERBEROS_V4 SASL mechanism SHOULD be used in
preference to the old telnet Telnet authentication mechanism.

The author mechanism, unless
encryption without integrity protection is not aware of implementation of Kerberos V5 via desired.

Both the SASL GSSAPI mechanism and the old Telnet authentication option. Therefore
option offer Kerberos V5 mechanisms. The only difference is that
the GSSAPI SASL GSSAPI Kerberos 5 mechanism is includes integrity protection
not available via the preferred method for old authentication and encryption options. A
server supporting Kerberos V5. [NOTE: anyone
else know of a Kerb5 telnet?] V5 SHOULD implement the old Kerberos V5
authentication option for backwards compatibility.

4. SASL Telnet Option

The SASL telnet option is telnet option number XXX. For historical
reasons, the GSSAPI/SASL service name for this SASL profile of SASL is "rcmd".

#define TELOPT_SASL XXX

The SASL Telnet option is Telnet option number XXX. It has the
following subnegotiation options:

#define TELSASL_LIST

LIST 0
#define TELSASL_START
START 1
#define TELSASL_STEP
STEP 2
#define TELSASL_SUCCESS
CANCEL 3
#define TELSASL_FAIL
DONE 4

The DONE subnegotiation option has the following codes:

SUCCESS 0
CANCELLED 1
BADAUTH 2
BADPROT 3
NOTAUTHZ 4
EXPIRED 5
ENCRYPT 6
TOOWEAK 7
TRANS 8
DISABLED 9

The SASL telnet Telnet option is negotiated only one way. The server
offers asks
the client to use SASL option with "WILL "DO SASL" and the client announces
support with "DO SASL." a "WILL SASL" message. Once the option is
successfully negotiated, the server sends the LIST subnegotiation
containing an ASCII string with a space separated list of available
SASL mechanisms available: mechanisms:

S: IAC WILL DO SASL
C: IAC DO WILL SASL
S: IAC SB SASL LIST "KERBEROS_V4 GSSAPI CRAM-MD5 OTP-SHA1" OTP" IAC SB

The client then sends the START subnegotiation to begin a SASL exchange
with the server. This The START subnegotiation contains the desired
mechanism name optionally followed by an ASCII NUL character followed by the and an
initial client response, if present. response. The client is not required to wait for
the LIST message from the server prior to sending the a START message.

C: IAC SB SASL START "CRAM-MD5" NUL IAC SE

This is followed by a series of STEP messages containing SASL
messages for the client and server respectively:

S: IAC SB SASL STEP
"<1896.697170952@postoffice.reston.mci.net>" IAC SE
C: IAC SB SASL STEP "tim b913a602c7eda7a495b4e6e7334d3890" IAC SE
Note that it is important to perform IAC doubling if the octet
value hexidecimal FF 255 occurs in any SASL data. This applies to data in the
START, STEP and DONE suboptions.

When a client receives a STEP message from the server, it MAY
cancel the authentication with the CANCEL message. The server will
respond with a DONE CANCELLED message. If the client wishes to
begin a new authentication, it MAY send a START message without
waiting for the server DONE CANCELLED message.

C: IAC SB SASL CANCEL IAC SE
S: IAC SB SASL DONE CANCELLED IAC SE

The server indicates successful completion of the exchange by
sending the "SUCCESS" DONE subnegotiation with SUCCESS status, which MAY
contain an optional final server authentication data (usually for mutual
authentication step. purposes).

S: IAC SB SASL DONE SUCCESS IAC SE

If a SASL security layer is negotiated, it begins on the server end
immediately after the SASL DONE SUCCESS subnegotiation, and begins on
the client end immediately after the last client START or STEP
subnegotiation once the SUCCESS subnegotiation is received.

For those cases where a security layer including integrity
protection is negotiated, the server SHOULD send another LIST
suboption message matching the one initially sent. If the client
supports any stronger authentication mechanism, it SHOULD verify
that the new LIST suboption matches the one sent prior to
authentication.

The server indicates failure by sending the FAIL DONE message with an
optional error code: a
code other than SUCCESS, followed by a human readable string in the
character set currently active on the Telnet channel. If no
character set has been negotiated through prior agreement or the
Telnet CHARSET option [TELNET-CHARSET], then UTF-8 [UTF-8] is
assumed.

S: IAC SB SASL FAIL DONE BADAUTH "Authentication Failed" IAC SE

The following error codes are defined:

#define TELSASL_BADAUTH 0 /* authentication failed */
#define TELSASL_BADPROT 1 /* protocol violation */
#define TELSASL_NOTAUTHZ 2 /* authorization failed */
#define TELSASL_EXPIRED 3 /* passphrase/credentials expired */
#define TELSASL_ENCRYPT 4 /* encryption defined by this specification. When
in doubt of the appropriate error code, the BADAUTH error code
should be used. Additional error codes MAY be defined by future
standards track or stronger mech needed */
#define TELSASL_TOOWEAK 5 /* mechanism too weak for user */
#define TELSASL_TRANS 6 /* transition needed to use new mech */
#define TELSASL_DISABLED 7 /* account disabled */ IESG approved experimental RFCs.

CANCELLED
The authentication was cancelled by the client.

BADAUTH
This indicates that the user does not exist or the
authentication failed for a reason other than those listed
below.

BADPROT
This indicates the client attempted to use a mechanism not
supported by the server, or the protocol for the SASL
mechanism was not followed.

NOTAUTHZ
This indicates the client successfully authenticated, but is
not authorized to login to the service with the requested SASL
authorization identity.

EXPIRED
This indicates that the client passphrase, one time passphrase
or public key
certificate or other credential has expired and can be updated
with an appropriate passphrase/credential change protocol.

ENCRYPT
This indicates that the requested client mechanism is not
permitted without an encryption layer, such as that provided
by TLS. The client may activate such encryption, or try a
stronger mechanism.

TOOWEAK
This indicates that security policy does not permit the
requested user to use the requested mechanism. For example,
an administrative user might be required to use a stronger
mechanism.

TRANSThis

TRANS
This indicates the user has a valid verifier in a server
authentication database but the requested mechanism can not be
used with that verifier. This also indicates that if the
client changes the passphrase or does a one-time
authentication with a plaintext clear-text passphrase mechanism
(preferably encrypted), then the appropriate authentication
database for the requested mechanism will be initialized.

DISABLED
This indicates that the user's account has been disabled. The
user must contact a system administrator to get their account
re-enabled.

10.

5. Formal Syntax

The following formal syntax uses ABNF [ABNF]:

IAC = %d255 ; standard Telnet symbols
DO = %d253
WILL = %d251
SB = %d250
SE = %d240
SASL = %dXXX ; Telnet SASL option
LIST = %d0 ; Telnet SASL sub-options
START = %d1
STEP = %d2
CANCEL = %d3
DONE = %d4

; Miscellaneous single-character symbols
DIGIT = %d30-39 ; US-ASCII digit character
UPALPHA = %d65-90 ; Uppercase alphabetic characters
MECH-CHAR = %d65-90 / DIGIT / "-" / "_"
SAFE-DATA = %d0-254 ; octets which don't need quoting
TEXT = %d1-254 ; human readable text
SP = %d32 ; US-ASCII space
NUL = %d0 ; US-ASCII NUL

; Miscellaneous multi-character symbols
quoted-255 = %d255 %d255
sasl-mech = 1*20mech-char
subopt-data = SAFE-DATA / quoted-255
text = *subopt-data ; human readable text
sasl-data = *subopt-data
success = %d0 sasl-data
error = %d1-254 text

; Telnet SASL messages
sasl-do = IAC DO SASL
sasl-will = IAC WILL SASL
sasl-list = IAC SB SASL LIST *(sasl-mech SP) sasl-mech IAC SE
sasl-start = IAC SB SASL START sasl-mech [NUL sasl-data] IAC SE
sasl-step = IAC SB SASL STEP sasl-data IAC SE
sasl-cancel = IAC SB SASL CANCEL IAC SE
sasl-done = IAC SB SASL DONE (success / error) IAC SE

6. Security Considerations

This inherits the security considerations of SASL [SASL] and any
underlying mechanism used.

The SASL LIST subnegotiation is not integrity protected and is thus
susceptible to tampering by an active attacker. The client can
address There are two ways
to mitigate this issue by having a configurable list of acceptable
mechanisms. In addition, if a SASL integrity protection layer is
negotiated on, the server SHOULD re-issue the SASL LIST
subnegotiation after the integrity layer is active so the client
has attack: (1) have the option of checking for tampering. A client which supports explicitly configured
to use a weaker integrity protected specific mechanism and never fall back to a stronger mechanism
SHOULD weaker one.
(2) have the client configurable to require integrity protection,
and verify that the re-issued SASL LIST subnegotiation suboption value is unchanged
if the weaker same both before
and after the integrity protected mechanism protection is used. applied.

With some SASL mechanisms, the ENCRYPT or TOOWEAK error codes will
be generated after sensitive information has been exposed. For
this reason, clients SHOULD be configurable to disable weaker
mechanisms which might reveal sensitive information and SHOULD do
so for user, mechanism and server combinations which result in
these error codes.

The TRANS error code could be spuriously generated by an active
attacker. For this reason, the client SHOULD NOT use a weaker
mechanism in response to a TRANS error code without explicit user
permission. The TRANS error code can also be used to probe for
untransitioned users at a site. For this reason, sites must
consider the tradeoffs between a user-friendly transition to a
stronger mechanism and the risks entailed by permitting such
transitions.

11.

Telnet server and client implementations MUST check for buffer
overrun on Telnet subnegotiations and deal with more data than will
fit in an internal buffer gracefully.

7. References

[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997.

[CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
for Simple Challenge/Response", RFC 2195, MCI, September 1997.

[GSSAPI] Linn, "Generic Security Service Application Program
Interface, Version 2", RFC 2078, OpenVision Technologies, January
1997.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.

[OTP-SASL] Newman, "One Time Password C., "The One-Time-Password SASL mechanism", work in progress. RFC
2444, Innosoft, October 1998.

[SASL] Myers, "Simple Authentication and Security Layer (SASL)",
RFC 2222, Netscape Communications, October 1997.

[SCRAM] Newman, "Salted Challenge Response Authentication Mechanism
(SCRAM)", work in progress.

[TELNET] Postel, J., Reynolds, J., "TELNET PROTOCOL SPECIFICATION",
RFC 854, ISI, May 1983.

[TELNET-AUTH] Borman, "Telnet Authentication Option", RFC 1416,
Cray Research, Inc., February 1993.

[TELNET-CHARSET] Gellens, R., "TELNET CHARSET Option", RFC 2066,
Unisys, January 1997.

[TELNET-ENC] Ts'o, T., "Telnet Data Encryption Option", work in
progress.

[TELNET-KRB] Borman, "Telnet Authentication: Kerberos Version 4",
RFC 1411, Cray Research, Inc., January 1993.

12.

[UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
RFC 2279, Alis Technologies, January 1998.

8. Author's Address

Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA

Email: chris.newman@innosoft.com