Subject: RE: Rough, first draft for using TLS with TELNET

From: "Erickson, Rodger" <[email-masked]>
Date: Sat, 15 Nov 1997 11:04:56 -0800

Michael,

        I've been doing some thinking on this issue and I have some
comments I'd like to toss out:

        The industry seems to be coming along rather slowly when it
comes to Digital Certificate Infrastructure.  As a result, the preferred
method of SSL/TLS Authentication (for now) should be Server-side only.
The level of SSL authentication is really an SSL negotiation issue and
we probably should be careful about specifying it in our document.
Maybe it would be sufficient to point out infrastructure problems and
suggest that if a server wants to support client-side authentication
that it SHOULD be disabled by default and MUST be configurable (i.e. the
customer can turn it on/off).

        Customers have a real need to authenticate clients using
mechanisms other than traditional host security.  This is especially
true when one considers the problem of printer emulation where there
isn't really any host security provided (this is an issue that Terry at
Boeing has expressed interest in to this group).
        Given the compatibility issues with RFC1416 and TLS and what
we're trying to accomplish, I would suggest the following mechanism:
1)      Use the RFC1416 mechanism to specify that a particular security
mechanism will be used.
2)      Define two new options: a) TLS, b) TLS with client
authentication
3)      If (a) is selected, normal TN negotiation begins as soon as the
TLS negotiation has ended (i.e. encryption is "on")
4)      If (b) is selected, an authentication step follows TLS
negotiation (i.e. authentication data is encrypted).  In this
authentication exchange, the client sends a packet that contains a
userid/password.  The server responds with SUCCESS or some error code.
(NOTE: We could use the format defined in RFC1929 (userid/password
support authentication in Socks5) for this authentication exchange).
Once this authentication step succeeds, normal TN negotiation ensues.

        This mechanism has some nice properties:
1)      It doesn't ask RFC1416 to handle things it can't.
2)      It is still general enough to apply to all telnet protocols
3)      It solves client authentication in a straightforward manner
4)      Since the data is encrypted at this point, we don't need to
worry about the userid/password information being vulnerable as it
passes over the network.
5)      Authenticating at the TN server closes the printer session
security hole

        Let's discuss this further at TIE III.  I look forward to seeing
you there.

Rodger D. Erickson
Technologist
Wall Data Inc.
[email-masked]
(314) 721-4640

        -----Original Message-----
        From:   Michael Boe [SMTP:[email-masked]]
        Sent:   Wednesday, October 08, 1997 2:42 AM
        To:     [email-masked]
        Cc:     [email-masked]
        Subject:        Rough, first draft for using TLS with TELNET

        Internet Engineering Task Force
Michael Boe
        INTERNET-DRAFT DRAFT
Cisco
        Systems
                                                                     20
September, 1997

                             TLS Authentication for TELNET

        1   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 the 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.
        Its 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 (Africe), ftp.nordu.net (Europe),
        munnari.oz.au (Pacific Rim), ds.internic.net (US East Cost), or
        ftp.isi.edu (US West Coast).

        Intent of Draft

        This draft is really just writing down what's been done in one
working
        TELNET implementation where TLS is used: the SSLeay SSLTelnet
package.
        This seems as good a starting point as any. I would particularly
like
        feedback and discussion on whether the RFC1416 (IP AUTHENTICATE)
way of
        doing things is sensible.

        I'm hoping this draft provides some focus on the following
issues:

           o how client and server can achieve TLS/SSL-based TELNET
connections.

           o how TLS can co-exist on the same server (or client) program
with
             other authentication techniques.

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

           o the limitations (futility?) of attempting to ``negotiate''
TLS at
             the TELNET level.

        I did not include descriptive narrative showing how things could
be
        implemented. Although this is a ``good'' thing in general with
RFCs, it
        makes initial understanding a bit harder. So please question the
draft
        is soemthing appears pointless or obscure.

        One thing I have not addressed is the minimum set of
cipher-suites that
        must be supported by all clients and servers. The IETF looks
like it is
        settling on TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, which is DSS
certificates
        and triple-DES and SHA MAC. This is not what comes standard with
Netscape
        SSL 3.0...but then, supposedly SSL is just a fallback in case
one of the
        implementations is not compliant with this spec :-).

        2   Introduction

        The TLS protocol (formerly known as SSL) can shield a connection
from
        tampering and eavesdropping. One protocol which can benefit from
the
        security TLS offers is Telnet [TELNET]. Although other security
        mechanisms have been used with Telnet (e.g. KERBEROS [KTELNET]),
TLS
        offers a broad range of security levels that allow sites to
proceed at an
        "evolutionary" pace in deploying authentication and
authorization
        policies, databases and distribution methods.

        TLS at most offers only authentication of the peers conducting
the TLS
        dialog. In particular, it does not offer the possibility of the
client
        providing separate credentials for authorization than were
presented for
        authentication. SASL [SASL] is a framework designed to do
exactly such
        separation of authentication from authorization. In particular,
the
        SASL "EXTERNAL" mechanism caters to authorizing the client
without
        invoking the SASL mechanism. Traditional TELNET servers have
operated
        without such early presentation of authorization credentials for
many
        reasons (most of which are historical). However, recent
developments in
        TELNET server technology make it advantageous for the TELNET
server to
        know the authorized capabilities of the remote client before
choosing a
        communications link (be it `pty' or SNA LU) and
link-characteristics to
        the host system (note that the ``upstream'' link be local to
server).

        This specification defines extensions to TELNET which allow TLS
to be
        activated early in the lifetime of the TELNET connection. It
defines a
        set of advisory security-policy response codes for use when
negotiating
        TLS over TELNET. The specification also defines presentation and
        acceptance procedures for SASL EXTERNAL-style authorization
credentials

        Michael Boe
[Page 2]

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

        for use with TELNET (whether or TLS is the authentication
mechanism
        used).

        3   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
[KEYWORDS].

        Formal syntax is defined using ABNF [ABNF].

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

        4   TELNET AUTHENTICATE TLS Command

        RFC1416 [RFC1416] defines protocol steps that can be taken such
that
        telnet servers and clients can authenticate each other. These
protocol
        steps have been used to authenticate clients via Kerberos
[RFC1411]. The
        base behavior of RFC1416 is to allow the two participants to
negotiate
        which authentication protocol is to be used on the connection,
and to
        subsequently exchange authentication details for the chosen
        authentication details.

        Unfortunately, the protocol has some features which make using
it in the
        spirit of RFC1416 with TLS difficult. Specifically:

           o The format of the RFC1416 authentication dialog does not
fit TLS,
             which has a very specific, wire-level dialog at odds with
the
             double-exchange authentication dialog set forth in
[RFC1416].

           o RFC1416 doesn't address other security needs, such as
encryption.
             TLS addresses this as part of the negotiation.

        However, using RFC1416 to negotiate TLS is attractive for two
reasons.
        Firstly, it's a well-known mechanism that has been deployed in
several
        commercial products. Secondly, using RFC1416 to negotiate the
use of TLS
        is already being used by products in the field. Products based
on the
        SSLeay toolkit [SSLEAY] are using this negotiation method today.

        Michael Boe
[Page 3]

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

        4.1   Attempting to Negotiate TLS

        The server initiates all attempts to negotiate TLS. It starts
with the
        standard [TNETAUTH] manner. The authentication-type has a
mnemonic of
        AUTHTYPE_SSL with a value of 7 (decimal). The authentication
policy
        modifier (or AUTH_HOW_MASK bits) MUST be set to the following:

        AUTH_CLIENT_TO_SERVER
        AUTH_HOW_ONE_WAY

        Notice that the above combination makes no semantic sense; the
actual
        TLS negotiation is the point at which the two parties determine
how
        authentication is to occur. This particular setting merely
determines
        which party is to speak first.

        The client, in response to the server's AUTH SEND sequence,
sends an AUTH
        IS message with a data payload of one octet: AUTH_SSL_START.
After send
        the AUTH IS message, the client MUST NOT send any data until the
server
        responds with an AUTH REPLY message.

        The server MUST respond to the client's AUTH IS message in one
of two
        ways: if the server is willing to start transport-level TLS
        negotiations, it will send an AUTH REPLY message with a data
payload of
        AUTH_SSL_ACCEPT. Otherwise, the server rejects the TLS
negotiation
        attempt by sending a reply message with a data payload of
        AUTH_SSL_REJECT.

        Here are the decimal values of the TLS-specific AUTHENTICATION
data:

        AUTH_SSL_START   1
        AUTH_SSL_ACCEPT  2
        AUTH_SSL_REJECT  3

        When the client receives the AUTH_SSL_ACCEPT token, it begins
TLS-level
        negotiation. Note that TLS-level datastream rules are not
subject to
        TELNET syntax; that is, hexidecimal octet value 0xFF is not
interpreted
        as IAC.

        If the server sends the AUTH_SSL_REJECT token, it considers the
TLS
        authentication attempt to be finished. The TCP connection may be
shut
        down by either side, or it may be continued. If continued,
neither side
        should again attempt TLS negotiation on that connection.

        Michael Boe
[Page 4]

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

        4.2   After TLS-level negotiation is finished

        If TLS-level startup is successful, then the TELNET connection
        continues. All TELNET data passing ``on the wire'' is subject to
the
        encryption and packaging rules of TLS; such data is decrypted
and
        de-packaged before being presented to the remote TELNET entity.

        4.3   Drawbacks of the fixed CLIENT_ONE_WAY scheme

        There is a drawback to the (in essence) not negotiating the
details of
        the TLS negotiation in the TELNET layer. If the TLS negotiation
fails,
        the TCP connection will be broken, and the two sides will have
no chance
        at attempting any other authentication/security scheme such as
Kerberos
        or SASL. That is, TLS is the end of road when it comes to TELNET
        authentication attempts.

        [mboe: I did it this way for three reasons:

         1.  Firstly, the [?] package does it this way.

         2.  Secondly, the implementors of clients and servers can
(should?)
             attempt to negotiate some SASL-based scheme before trying
TLS.

         3.  Thirdly, doing the negotiation details first in TELNET and
then in
             TLS seemed wasteful and requiring more communication
between the
             client and the TLS-layer than I thought needful

        Comments, please]

        5   Providing SASL-compatible authorization credentials

        The RFC1416 method of providing authorization credentials is to
send a
        AUTHENTICATION NAME subnegotiation from the client to the server
before
        the actual authentication dialog occurs. This method is flawed
in
        several ways, the most serious being that ``man in the middle''
attacks
        can change the value of the remote-user name provided in the
        subnegotiation message.

        Servers providing the ability for clients to be authorized
differently
        from the the TLS authenticated identities SHOULD mandate the use
of the
        SASL ``EXTERNAL'' authorization mechanism. See [blah] for
details on how

        Michael Boe
[Page 5]

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

        the EXTERNAL authorization mechanism is implemented in TELNET.
Clients
        associated with end-users MAY attempt such SASL-based
authorization.

        Clients which are proxy-servers for remote clients SHOULD either
attempt
        SASL-based authorization or monitor and block attempts by
end-clients to
        do such SASL-based authorization. Not doing one of these two
allows the
        end-user-client to authorize itself as the proxy-server.

        6   Display of security levels

        The TELNET client and server may, during the TLS protocol
negotiation
        phase, choose to use a weak cipher suite due to policy, law or
even
        convenience. It is, however, important that the choice of weak
cipher
        suite be noted as being commonly known to be vulnerable to
attack. In
        particular, both server and client software should note the
choice of
        weak cipher-suites in the following ways:

           o If the TELNET endpoint is communicating with a human
end-user, the
             user-interface SHOULD display the choice of weak
cipher-suite.

           o The TELNET endpoints SHOULD log the exact choice of
cipher-suite as
             part of whatever logging/accounting mechanism normally
used.

        7   TLS Variants and Options

        TLS has different versions and different cipher suites that can
be
        supported by client or server implementations. The following
        subsections detail what TLS extensions and options are
mandatory. The
        subsections also address how TLS variations can be accommodated.

        7.1   Support of previous versions of TLS

        TLS has its roots in SSL 2.0 and SSL 3.0. Server and client
        implementations may wish to support for SSL 3.0 as a fallback in
case TLS
        3.1 or higher is not supported. This is permissible; however,
client
        implementations which negotiate SSL3.0 MUST still follow the
rules in
        [section blah] concerning disclosure to the end-user of
transport-level
        security characteristics.

        Negotiating the use of SSL 3.0 is done as part of the TLS
negotiation; it
        is detailed in [TLS-draft?]. Negotiating SSL 2.0 is not
recommended.

        Michael Boe
[Page 6]

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

        8   Protocol Examples

        The following sections provide skeletal examples of how TELNET
clients
        and servers can negotiate TLS.

        8.1   Successful TLS negotiation

        The following protocol exchange is the typical sequence that
starts TLS.

        //typical successful opening exchange
          S: IAC DO AUTHENTICATION
          C: IAC WILL AUTHENTICATION
          S: IAC SB AUTHENTICATION SEND SSL CLIENT_ONE_WAY IAC SE
          C: IAC SB AUTHENTICATION IS SSL CLIENT_ONE_WAY AUTH_SSL_START
IAC SE
          S: IAC SB AUTHENTICATION REPLY CLIENT_ONE_WAY AUTH_SSL_ACCEPT
IAC SE
          [TLS transport-level negotiation ensues]
          [TLS transport-level negotiation completes]
          [either side free to transmit TELNET commands or data]

        8.2   Unsuccessful TLS negotiation

        This example assumes that the server does not wish to allow the
TELNET
        session to procede without TLS security; however, the client's
version
        of TLS does not interoperate with server's.

        //typical successful opening exchange
          S: IAC DO AUTHENTICATION
          C: IAC WILL AUTHENTICATION
          S: IAC SB AUTHENTICATION SEND SSL CLIENT_ONE_WAY IAC SE
          C: IAC SB AUTHENTICATION IS SSL CLIENT_ONE_WAY AUTH_SSL_START
IAC SE
          S: IAC SB AUTHENTICATION REPLY CLIENT_ONE_WAY AUTH_SSL_ACCEPT
IAC SE
          [TLS transport-level negotiation ensues]
          [TLS transport-level negotiation terminates in failure]
          [either side disconnects the TELNET session]

        8.3   Unsuccessful TLS negotiation falling back to no auth

        In this example the client does not support TLS. So the server
goes on
        without the authentication step (not recommended).

        Michael Boe
[Page 7]

        INTERNET-DRAFT DRAFT   TLS Authentication for TELNET   20
September, 1997

        //client doesn't support SSL authentication
          S: IAC DO AUTHENTICATION
          C: IAC WILL AUTHENTICATION
          S: IAC SB AUTHENTICATION SEND SSL CLIENT_ONE_WAY IAC SE
          C: IAC SB AUTHENTICATION IS SSL NULL IAC SE
          [either side continues the TELNET conversation]

        Michael Boe
[Page 8]