[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

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

                   Using SASL and GSSAPI with Telnet

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

     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 (US East
     Coast), or ftp.isi.edu (US West Coast).


     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.  It is desirable to have telnet leverage
     development of new security services for new protocols.  Therefore,
     future use of the Telnet authentication option is deprecated in
     favor of a new SASL [SASL] authentication option suitable for use
     with SASL and GSSAPI [GSSAPI] mechanisms.  This service can
     complement use of TLS with Telnet [TELNET-TLS].

     [NOTE: 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 on the tn3270e@list.nih.gov mailing list
     with a subscription address of listserv@list.nih.gov.  Private
     comments may be sent to the author].

Newman                                                          [Page 1]

Internet Draft       Using SASL/GSSAPI with Telnet          January 1998

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"

     Formal syntax is defined using ABNF [ABNF].

     In examples, "C:" and "S:" indicate lines sent by the client and
     server respectively.

2. Mechanism Requirements

     It is important that all telnet implementations are capable of
     interoperable authentication without the use of unencrypted
     plaintext passwords.

     For the usage scenarios with the TN3270 protocol, it looks like the
     TLS protocol in combination with traditional embedded plaintext
     passwords will be preferable because TN3270 is often performed by a
     proxy with no knowledge of the users.  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, 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 to be the mandatory to implement choice for a number of
     services) is particularly unsuited to the Telnet protocol as a
     machine which supports both CRAM-MD5 and remote login risks
     exposing the authentication database and thus risks an attacker
     gaining the ability to impersonate all users to any CRAM-MD5
     authenticated service with the same passphrase.

     The SCRAM-MD5 [SCRAM] mechanism might suffice, but is probably too
     new to gain rough concensus.  This leaves OTP-SHA1 [OTP-SASL] as
     the preferred choice for the mandatory to implement lightweight
     authentication mechanism in combination with this telnet extension.

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

Newman                                                          [Page 2]

Internet Draft       Using SASL/GSSAPI with Telnet          January 1998

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 services.  Currently deployed Kerberos V4
     telnet implementations use encryption support which was documented
     in an expired internet draft and is susceptible to active attacks.

     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 authentication mechanism.

     The author is not aware of implementation of Kerberos V5 via the
     old Telnet authentication option.  Therefore the GSSAPI SASL
     mechanism is the preferred method for Kerberos V5.  [NOTE: anyone
     else know of a Kerb5 telnet?]

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 is

     #define TELOPT_SASL XXX

     It has the following subnegotiation options:

     #define TELSASL_LIST    0
     #define TELSASL_START   1
     #define TELSASL_STEP    2
     #define TELSASL_SUCCESS 3
     #define TELSASL_FAIL    4

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


Newman                                                          [Page 3]

Internet Draft       Using SASL/GSSAPI with Telnet          January 1998

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


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

         "<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 occurs in any SASL data.  The server indicates
     successful completion of the exchange by sending the "SUCCESS"
     subnegotiation which MAY contain an optional final mutual
     authentication step.


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

     The server indicates failure by sending the FAIL message with an
     optional error code:


     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 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 */

          This indicates that the user does not exist or the

Newman                                                          [Page 4]

Internet Draft       Using SASL/GSSAPI with Telnet          January 1998

          authentication failed for a reason other than those listed

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

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

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

          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.

          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

     TRANSThis 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 passphrase mechanism
          (preferably encrypted), then the appropriate authentication
          database for the requested mechanism will be initialized.

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

10. Security Considerations

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

Newman                                                          [Page 5]

Internet Draft       Using SASL/GSSAPI with Telnet          January 1998

     The SASL LIST subnegotiation is not integrity protected and is thus
     susceptible to tampering by an active attacker.  The client can
     address 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 the option of checking for tampering.  A client which supports
     a weaker integrity protected mechanism and a stronger mechanism
     SHOULD verify the re-issued SASL LIST subnegotiation is unchanged
     if the weaker integrity protected mechanism is used.

     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

11. 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

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

     [OTP-SASL] Newman, "One Time Password SASL mechanism", work in progress.

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

Newman                                                          [Page 6]

Internet Draft       Using SASL/GSSAPI with Telnet          January 1998

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

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

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

12. Author's Address

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

     Email: chris.newman@innosoft.com

Newman                                                          [Page 7]