[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                          Jeffrey Altman
INTERNET-DRAFT draft-altman-telnet-starttls-02.txt
Expires:  16 July 2007
                                                      December 15, 2006

                       Telnet START-TLS Option

Status of this memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on 15 December 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

Telnet service has long been a standard Internet protocol. However, a
standard way of ensuring privacy and integrity of Telnet sessions has
been lacking. This document proposes a standard method for Telnet
servers and clients to use the Transport Layer Security (TLS) protocol.
It describes how two Telnet participants can decide whether or not to
attempt TLS negotiation, and how the two participants should process
authentication credentials exchanged as a part of TLS startup.

Contents

1    Introduction

2    Command Names and Codes (assigned by IANA)

3    Command Meanings

     3.1  Usage of commands and interactions with other Telnet options

     3.2  TLS Negotiation Failure

4    Authentication and Authorization

     4.1     Authentication of the Client by the Server

     4.1.1   PKI Server Authentication via TLS handshake

     4.1.2   Non-PKI Server Authentication via TLS handshake

     4.1.3   Telnet AUTH option

     4.1.4   Username and Password

     4.2     Authentication of the Server by the Client

     4.2.1   PKI-based Authentication via TLS handshake

     4.2.2   Non-PKI based authentication via TLS handshake

     4.2.3   Authentication by Telnet AUTH option

5    Security Considerations

     5.1     PKI-based certificate processing      .    .    .

     5.2     Client and Server authentication of anonymous TLS
             connections

     5.3     Display of security levels      .    .    .    .    .    .

     5.4     Trust Relationships and Implications    .    .    .    .

     5.5     Telnet negotation handling

6    TLS Variants and Options

     6.1     Support of previous versions of TLS      .    .    .    .

     6.2     Using Kerberos V5 with TLS       .    .    .    .    .    .

     6.3     TLS Channel Bindings for use with TELNET AUTH mechanisms

7    Protocol Examples

     7.1     Successful TLS negotiation      .    .    .    .    .    .

     7.2     Successful TLS negotiation, variation   .    .    .    .

     7.3     Unsuccessful TLS negotiation    .    .    .    .    .    .

     7.4     Authentication via Telnet Auth Kerberos 5 after TLS
             negotiation

8    IANA Considerations

9    Normative References

10   Authors

11   Credits

1    Introduction

This document describes the Telnet START_TLS option.  It allows TLS
to be activated at the beginning of a Telnet connection, using the IANA
assigned "telnet" port (IANA tcp\23), which can be used to provide
authentication and confidentiality.  This document also defines a set
of advisory security policy response codes for use when negotiating TLS
from within an existing Telnet session.

This specification addresses the interaction between the Telnet
client and server that requires private communications while
acknowledging it may only protect a portion of the total end-user to
application path. Specifically, it is often true that the Telnet server
does not reside on the target machine (it does not have access to a
list of identities which are allowed to access to that application-
server), and it is often true (e.g. 3270 access) that the telnet server
can not even identify that portion of the emulation stream which
contains user identification/password information. Additionally, it may
be the case that the Telnet client is not co-resident with the end user
and that it also may be unable to identify that portion of the data
stream that deals with user identity. This document assumes that there
is a trust relationship and appropriate protection to support that
relationship between the Telnet Server and the ultimate application
engine such that data on this path is protected and that the
application will authenticate the end user via the emulation stream as
well as use this channel to control access to information. It is
further assumed that the path between the end user and the client is
protected.

In order for the Telnet portion of the overall path between the
user and the application-server to be considered secure, the Telnet
data stream must be authenticated and provide confidentiality and integrity
protection.  This is accomplished by establishing a shared secret
between the client and server.  This shared secret is used to encrypt
the flow of data and (just as important) require the client to verify
that it is talking to correct server (the one that the application-
server trusts rather than an unintended man-in-the-middle) with the
knowledge that the emulation stream itself will be used by the
application-server to verify the identity of the end-user.  Rather than
create a new proprietary protocol which accomplishes these goals this
document defines the use of an existing IETF protocol, Transport Layer
Security (TLS).

The Telnet [TELNET] application protocol can certainly benefit from the
use of TLS. Since 1992 Telnet has supported over a dozen forms of
end user authentication and encryption via the AUTH and ENCRYPT
options.  Since 1995, predecessors to TLS have been used to provide
privacy and integrity protection to Telnet data streams via the
undocumented Telnet AUTH SSL option and via the dedicated IANA assigned
port assignment ("telnets" tcp\992).  TLS offers a broad range of
security levels that allow sites to proceed at an "evolutionary" pace
in deploying authentication, authorization and confidentiality
policies, databases and distribution methods.

This document describes how TLS can be used to provide the following:

   o creation and refresh of a shared secret;

   o negotiation and execution of data encryption and optional
     compressesion;

   o primary negotiation of authentication; and, if chosen

   o execution of public-key or symmetric-key based authentication.

TLS at most offers only authentication of the peers conducting the TLS
dialog. In particular, it does not support the client providing
different credentials for authorization than were presented for
authentication.  After the establishment of peer-to-peer trust using
TLS, other forms of end user authentication including Telnet AUTH may
be used to provide credentials for use in determining end user
authorization.

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 (be that "upstream" link local or remote to the server).
Thus, we expect to see the use of client authorization to become an
important element of the Telnet evolution. Such authorization methods
may require certificates presented by the client via TLS, or by the use
of Telnet AUTH option, or some other as yet-to-be-standardized method.

Conventions Used in this Document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  RFC 2119. [KEYWORDS].

  Formal syntax is defined using Augmented BNF for Syntax
  Specifications [ABNF].

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


2  Command Names and Codes (assigned by IANA)

   START_TLS   46 (decimal)

   FOLLOWS      1 (decimal)


3 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 did the passive TCP open (TCP LISTEN state), and the
   "client" is the side of the connection that did the active open.

   IAC DONT START_TLS

     The sender is either not a server or is not interested in
     negotiating a TLS connection.

   IAC WONT START_TLS

     The sender is either not a client or is not interested in
     negotiating a TLS connection.

   IAC DO START_TLS

     The server side of the connection sends this command to indicate
     a desire to negotiate a TLS connection.  This command MUST NOT
     be sent by the client.  If this command is received by the server,
     it MUST be refused with IAC WONT START_TLS.

   IAC WILL START_TLS

     The client side of the connection sends this command to indicate
     a desire to negotiate a TLS connection.  This command MUST NOT
     be sent by the server.  If this command is received by the client,
     it MUST be refused with IAC DONT START_TLS.

   IAC SB START_TLS FOLLOWS IAC SE

     The FOLLOWS sub-command is sent to indicate that the next byte of
     data received after this command MUST be a TLS negotiation as
     described in [TLS].  This sub-command is sent by both the client
     and the server.  After this sub-command has been sent, the sender
     MUST NOT respond to nor initiate any additional telnet commands or
     sub-commands.  When this sub-command has been sent and received
     the TLS negotiation will commence.  When sent by a client this
     sub-command will be followed by a TLS ClientHello.  When sent by a
     server this sub-command will be followed by a TLS ServerHello.

3.1  Usage of commands and interactions with other Telnet options

The START_TLS option is an asymmetric option, with the server side
allowed to send IAC DO START_TLS and the client allowed to send
IAC WILL START_TLS. Sub-commands are used to synchronize the link
in preparation for negotiating TLS. This synchronization takes
the form of a three-way handshake:

 1.  As per normal Telnet option processing rules, the client MUST
     respond to the server's IAC DO START_TLS with either IAC WONT
     START_TLS or IAC WILL START_TLS (if it hasn't already done
     so).  Once the client has sent IAC WILL START_TLS and received
     IAC DO START_TLS, it MUST immediately send a FOLLOWS sub-command
     (IAC SB START_TLS FOLLOWS IAC SE) to indicate it is ready to begin
     a TLS negotiation.  Once the FOLLOWS sub-command has been sent,
     the client MUST ignore all telnet negotiations except for the
     FOLLOWS sub-command.  When the FOLLOWS sub-command has been
     received the client MUST halt use of the telnet protocol, reset
     the telnet state machine and begin a TLS negotiation by sending a
     ClientHello message.

 2.  If the client initiates by sending IAC WILL START_TLS, the server
     MUST respond with either IAC DO START_TLS or IAC DONT START_TLS.

 3.  The server SHOULD NOT send additional Telnet data or commands
     after sending IAC DO START_TLS except in response to client Telnet
     options received until after it receives either a negative
     response from the client (IAC WONT START_TLS) or a successful
     negotiation of TLS has occurred.  If the client's START_TLS option
     response is negative, the server is free to send additional Telnet
     data or commands. If the client's response is affirmative (IAC
     WILL START_TLS), then the server MUST send the FOLLOWS sub-command
     (IAC SB START_TLS FOLLOWS IAC SE) and await the FOLLOWS sub-
     command from the client.  When the FOLLOWS sub-command has been
     sent and received the server MUST halt use of the Telnet protocol,
     reset the telnet state machine, and begin a TLS negotiation by
     sending a TLS ServerHello message.

 4.  If both START_TLS and AUTH [AUTH] are offered, START_TLS SHOULD be
     sent first and MUST take precedence if both are mutually negotiated.
     AUTH MAY be renegotiated after successful establishment of the TLS
     session if end-user authentication via a supported method is
     desired.

 5.  If a TLS session has been established, the ENCRYPT [ENCRYPT] option
     MUST NOT be negotiated in either direction.

 6.  When the FOLLOWS sub-command has been sent and received the Telnet
     state machine is reset.  This means that the state of all telnet
     options is reset to the WONT/DONT state and any data received via
     subcommands is forgotten.  After a sucessful TLS negotiation the
     Telnet negotiations will be restarted as if a new connection had
     just been established with one exception.  Since TLS is already in
     use, the START_TLS option MUST NOT be negotiated.

3.2   TLS Negotiation Failure

The behavior regarding TLS negotiation failure is covered in [TLS], and
does not indicate that the TCP connection be broken; the semantics are
that TLS is finished and all state variables cleaned up. The TCP
connection may be retained.

However, it's not clear that either side can detect when the last of
the TLS data has arrived. So if TLS negotiation fails, the TCP
connection SHOULD be reset and the client MAY reconnect. To avoid
infinite loops of TLS negotiation failures, the client MUST remember to
not negotiate START_TLS if reconnecting due to a TLS negotiation failure
(if allowed by policy.)


4    Telnet Authentication and Authorization

Telnet servers and clients can be implemented in a variety of ways that
impact how clients and servers authenticate and authorize each other.
However, most (if not all) the implementations can be abstracted via
the following four communicating processes:

SES  Server End System. This is an application or machine to which
     client desires a connection. Though not illustrated here, a single
     Telnet connection between client and server could have multiple
     SES terminations.

Server  The Telnet server.

Client  The Telnet client, which may or may not be co-located with the
     CES. The Telnet client in fact be a gateway or proxy for
     downstream clients; it's immaterial.

CES  Client End System. The system communicating with the Telnet
     Client. There may be more than one actual CES communicating to a
     single Telnet Client instance; this is also immaterial with respect
     to Client and Server sucessfully exchanging authentication and
     authorization details. However, see Section 5.4 for a discussion
     on trust implications.

What is of interest here is how the Client and Server can exchange
authentication and authorization details such that these components can
direct Telnet session traffic to authorized End Systems in a reliable,
trustworthy fashion.

What is beyond the scope of this specification are several related
topics, including:

   o How the Server and SES are connected, and how they exchange data
     or information regarding authorization or authentication (if any).

   o How the Client and CES are connected, and how they exchange data
     or information regarding authorization or authentication (if any).

System-to-system communications using the Telnet protocol have
traditionally used no authentication techniques at the Telnet level.
More recent techniques have used Telnet to transport authentication
exchanges [AUTH].  In none of these systems, however, is a remote
system allowed to assume more than one identity once the Telnet
preamble negotiation is over and the remote party is connected to the
application-endpoint.  The reason for this is that the local party must
in some way inform the end-system of the remote party's identity (and
perhaps authorization). This process must take place before the remote
party starts communicating with the end-system. At that point it's too
late to change what access a client may have to an server end-system:
that end-system has been selected, resources have been allocated and
capability restrictions set.

This process of authentication, authorization and resource allocation
can be modeled by the following simple set of states and transitions:

`unauthenticated'    The local party has not received any credentials
     offered by the remote party.  A new Telnet connection starts in
     this state.

     The `authenticating' state will be entered from this state if the
     local party initiates the authentication process of the peer. The
     Telnet START_TLS negotiation is considered an initiation of the
     authentication process.

     The `authorizing' state will be entered from this state either if
     the local party decides to begin authorization and resource
     allocation procedures unilaterally, or if the local party has
     received data from the remote party destined for local end-system.

`authenticating'    The local party has received at least some of the
     credentials needed to authenticate its peer, but has not finished
     the process.

     The `authenticated' state will be entered from this state if the
     local party is satisfied with the credentials proferred by the
     client.

     The `unauthenticated' state will be entered from this state if the
     local party cannot verify the credentials proffered by the client
     or if the client has not proffered any credentials. Alternately,
     the local party may terminate the Telnet connection instead of
     returning it to the `unauthenticated' state.

`authenticated'   The local party has authenticated its peer, but has
     not yet authorized the client to connect to any end-system
     resources.

     The `authenticating' state will be entered from this state if the
     local party decides that further authentication of the client is
     warranted.

     The `authorizing' state will be entered from this state if the
     local party either initiates authorization dialog with the client
     (or engages in some process to authorize and allocate resources on
     behalf of the client), or has received data from the remote party
     destined for a local end-system.

`authorizing'   The local party is in the process of authorizing its
     peer to use end-system resources, or may be in the process of
     allocating or reserving those resources.

     The `transfer-ready' state will be entered when the local party is
     ready to allow data to be passed between the local end-system and
     remote peer.

     The `authenticated' state will be entered if the local party
     determines that the current authorization does not allow any
     access to a local end-system. If the remote peer is not currently
     authenticated, then the `unauthenticated' state will be entered
     instead.

`transfer-ready'    The party may pass data between the local end-
     system to its peer.

     The `authorizing' state will be entered if the local party (perhaps
     due to a request by the remote peer) deallocates the communications
     resources to the local-end system. Alternately, the local party may
     enter the `authenticated' or the `unauthenticated' state.

In addition to the "orderly" state transitions noted above, some
extraordinary transitions may also occur:

 1.  The absence of a guarantee on the integrity of the data stream
     between the two Telnet parties also removes the guarantee that the
     remote peer is who the authentication credentials say the peer is.
     Thus, upon being notified that the Telnet session is no longer
     using an integrity layer, the local party must at least deallocate
     all resources associated with a Telnet connection which would not
     have been allocable had the remote party never authenticated
     itself.

     In practice, this deallocation-of-resources restriction is hard to
     interpret consistently by both Telnet endpoints. Therefore, both
     parties MUST return to the initial Telnet state after negotiation
     of TLS. That is, it is as if the Telnet session had just started.

     This means that the states may transition from whatever the current
     state is to `unauthenticated'. Alternately, the local party may
     break the Telnet connection instead.

 2.  If the local party is notified at any point during the Telnet
     connection that the remote party's authorizations have been
     reduced or revoked, then the local party must treat the remote
     party as being unauthenticated. The local party must deallocate
     all resources associated with a Telnet connection which would not
     have been allocable had the remote party never authenticated
     itself.

     This too may mean that the states may transition from whatever the
     current state is to `unauthenticated'. Alternately, the local
     party may break the Telnet connection instead.

The above model explains how each party should handle the
authentication and authorization information exchanged during the
lifetime of a Telnet connection. It is deliberately fuzzy as to what
constitutes internal processes (such as "authorizing") and what is
meant by "resources" or "end-system" (such as whether an end-system is
strictly a single entity and communications path to the local party, or
multiples of each, etc).


Here's a state transition diagram, as per [RFC2360]:

             0        1         2         3            4
Events     | unauth   auth'ing  auth'ed   authorizing  trans-ready
-----------+--------------------------------------------------------
auth-needed| sap/1    sap/1     sap/1     sap/1        der,sap/1
auth-accept| -        ain/2     -         -            -
auth-bad   | -        0         wa/0      wa,der/0     der,sap/1
authz-start| szp/3    -         szp/3     -            -
data-rcvd  | szp/3    qd/1      szp/3     qd/3         pd/4
authz-ok   | -        -         -         4            -
authz-bad  | -        -         -         der/2        wa,der,szp/3

Action | Description
-------+--------------------------------------------
sap    | start authentication process
der    | deallocate end-system resources
ain    | authorize if needed
szp    | start authorization process
qd     | queue incoming data
pd     | process data
wa     | wipe authorization info

Event       |    Description
-------------+---------------------------------------------------
auth-needed  | authentication deemed needed by local party
auth-accept  | remote party's authentication creds accepted
auth-bad     | remote party's authentication creds rejected or expired
authz-start  | local or remote party starts authorization proceedings
data-rcvd    | data destined for end-system received from remote party
authz-ok     | authorization and resource allocation succeeded
authz-bad    | authorization or resource allocation failed or expired


4.1    Authentication of the Server by the Client

A secure connection requires that the client authenticate the identity
of the server.  How the authentication is performed depends upon the TLS
ciphersuite agreed upon during the negotiation.  As of this writing there are
three categories of ciphersuites supported by TLS: ciphersuites supporting
X.509 certificates (PKI), non-PKI ciphersuites, and anonymous ciphersuites.
The following sections detail how Server authentication should be performed
by the client for each ciphersuite category.

4.1.1  PKI-based Server Authentication via TLS handshake

When a PKI based ciphersuite is negotiated during the TLS negotiation, the
server will deliver an X.509 certificate to the client.  Before the
certificate MAY be used to determine the identity of the server, the
certificate MUST be validated as per [RFC3280].

Once validated the identity of the server is confirmed by matching the
DNS name used to access the host with the name stored in the
certificate.  If the certificate includes the `subjectAltName'
extension and it contains a `dNSName' object, then the client MUST use
this name as the identity of the server.  Otherwise, the (most
specific) commonName field in the Subject field if the certificate MUST
be used. Note that although the commonName field technique is currently
in wide use, it is deprecated and Certification Authorities are
encourage to use the dnsName instead.  Another possibility is that the
Subject Name field can consist of Domain Component assertions.  For example,
"dc=com, dc=example, dc=hostname".  Matching is performed using the
matching rules specified by [RFC3280].

In some cases, an IP address is used to access the host instead of
a DNS name.  In these cases, a 'subjectAltName' object of type
'iPAddress' MUST be present in the certificate and MUST exactly match
the IP address provided by the end user.

If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the user
the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error.  Automated
clients MUST log the error to an appropriate audit log (if available)
and SHOULD terminate the connection (with a bad certificate error.)
Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.

4.1.2  Non-PKI Server Authentication via TLS handshake

Non-PKI ciphersuites such as Kerberos v5 [TLSKERB] and Pre-Shared Keys
[TLSPSK] provide for server authentication.  Refer to the appropriate
RFC for details.

4.1.3  Server Authentication by Telnet AUTH option [AUTH]

If the TLS exchange used an anonymous ciphersuite such as Anonymous-Diffie-
Hellman (ADH) or if the X.509 certificate could not be validated, then
the session MUST be protected from a man-in-the-middle attack.  This
can be accomplished by using a Telnet AUTH [AUTH] method that provides
for mutual authentication(*) of the client and server; and which allows
the TLS Channel Binding data [TLS-CB] to be verified.  A failure to
successfully perform a mutual authentication with TLS Channel Binding
verification via Telnet AUTH MUST result in termination of the connection
by both the client and the server.

(*) The Telnet AUTH option supports both unilateral and mutual
authentication methods.  The distinction being that mutual
authentication methods confirm the identity of both parties at the end
of the negotiation.  A unilateral authentication method cannot be used
to verify the contents of the TLS client and server finished messages.
It is worth noting that TLS usually authenticates the server to the
client; whereas, Telnet AUTH usually authenticates the client to the
server when unilateral methods are used.

4.2    Authentication of the Client by the Server

After TLS has been successfully negotiated the server may not have the
client's identity (verified or not) since the client is not required to
provide credentials during the TLS exchange.  Even when the client does
provide credentials during the TLS exchange, the server may have a
policy that prevents their use.  Therefore, the server may not have
enough confidence in the client to move the connection to the
authenticated state.

If further client, server or client-server authentication is going to
occur post-TLS establishment, it MUST occur before any
non-authentication-related Telnet options are negotiated or data
is transmitted. When the first non-authentication-related Telnet
interaction is received by either participant, then the receiving
participant MAY drop the connection due to dissatisfaction with the
level of authentication.

If the server wishes to request a client certificate after TLS is
initially started (presumably with no client certificate requested), it
may do so. However, the server MUST make such a request immediately
after the initial TLS handshake is complete.

No TLS negotiation outcome, however trustworthy, will by itself provide
the server with the authorization identity if that is different from
the authentication identity of the client.

The following subsections detail how the client can provide the server
with authentication and authorization credentials.

4.2.1   PKI-based Authentication via TLS handshake

PKI-based authentication is used by the client transmitting an X.509
certificate to the host during the TLS handshake.  There is no standard
mechanism defined for how a client certificate should be mapped to a
authorization identity (userid).  There are several methods currently
in wide practice.  A telnet server compliant with this document may
implement zero, one or more than one of them.

The first method is to use information stored within the certificate
to determine the authorization identity.  If the certificate contains
an Common Name object then portions of it can be used as the
authorization identity.  If the Common Name contains an UID member,
then it can be used directly.  If the Common Name contains an Email
member, then it can be used if the specified domain matches the domain
of the telnet server.

The second method is to use the entire Subject Name as a entry to
lookup in a directory.  The directory provides a mapping between the
subject name and the authorization identity.

The third method is to use the entire certificate or the entire
distinguished name as a entry to lookup in a directory with the
directory providing a mapping between the certificate and the
authorization identity.

The first method is only practical if the certificates are being
issued by certification authority managed by the same organization as
the server performing the authorization.

The second and third methods can be used with certificates issued
by public certification authorities provided the certificates are
delivered to the organization performing the authorization in advance
via an authenticated method.  The second and third methods have the
added benefit that the certificates, if issued by the authorizing
organization, do not require that any personal information about the
subject be included in the certificate.  The Common Name field could be
filled only with gibberish to establish its uniqueness in the
directory.

4.2.2   Non-PKI Authentication via TLS handshake

TLS supports non-PKI authentication methods which can be used for
securely establishing authentication identities.

4.2.3   Telnet AUTH option

The Telnet AUTH option implements a variety of authentication methods
which can be used to establish authentication and authorization
identities.  Some methods (e.g., KERBEROS_IV and KERBEROS_V) allow
separate authentication and authorization identities to be provided.
Details on the use of the Telnet AUTH option and its authentication
methods can be found in [AUTH] and its related documents.  For a
current list of Telnet AUTH methods see [IANA].

4.2.4   Username and Password

When there is no other method of client authentication available
transmitting the username and password over a connection protected
by TLS is far superior to sending them in the clear.

The Username MAY be transmitted to the host via the Telnet New
Environment option's USER variable.


5    Security Considerations

Security is discussed throughout this document. Most of this document
concerns itself with wire protocols and security frameworks. But in
this section, client and server implementation security issues are in
focus.

5.1   PKI-based certificate processing

A complete discussion of the proper methods for verifying X.509
certificates and their associated certificate chains is beyond the
scope of this document.  The reader is advised to refer to the RFCs
issued by the PKIX Working Group.  However, the verification of a
certificate MUST include, but isn't limited to, the verification of the
signature certificate chain up to the trust anchor. The verification
SHOULD then continue with a check to see if the fully qualified host
name which the client connected to appears anywhere in the server's
certificate subject (DN).

If the certificate cannot be verified then either:

   o the end user MUST see a display of the server's certificate and be
     asked if he/she is willing to proceed with the session; or,

   o the end user MUST NOT see a display of server's certificate, but
     the certificate details are logged on whatever media is used to
     log other session details. This option may be preferred to the
     first option in environments where the end-user cannot be expected
     to make an informed decision about whether a mismatch is harmful.
     The connection MUST be closed automatically by the client UNLESS
     the client has been configured to explicitly allow all mismatches.

   o the connection MUST be closed on the user's behalf, and an error
     describing the mismatch logged to stable storage.

If the client side of the service is not interactive with a human
end-user, the Telnet connection SHOULD be dropped if this host check
fails.

5.2   Client and Server authentication of anonymous-TLS connections

When authentication is performed after the establishment of a TLS
session which uses an anonymous ciphersuite, it is imperative that the
authentication method protect against a man-in-the-middle attack by
verifying the contents of the client's and server's TLS finished
messages.  Without the verification of both the client and server's TLS
finished messages it is impossible to confirm that there is not a man-
in-the-middle listening and perhaps changing all the data transmitted
on the connection.

Verification of the TLS finished messages can be performed as part
of a Telnet AUTH option mutual authentication exchange (when using the
ENCRYPT_START_TLS flag.) This can be done at the same time the
verification of the authentication-type-pair is performed.

5.3    Display of security levels

The Telnet client and server MAY, during the TLS protocol negotiation
phase, choose to use a weak ciphersuite 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 ciphersuites 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 ciphersuite and
     the fact that such a ciphersuite may compromise security.

   o The Telnet endpoints SHOULD log the exact choice of ciphersuite
     as part of whatever logging/accounting mechanism normally used.

5.4    Trust Relationships and Implications

Authentication and authorization of the remote Telnet party is useful,
but can present dangers to the authorizing party even if the connection
between the client and server is protected by TLS using strong
encryption and mutual authentication. This is because there are some
trust-relationships assumed by one or both parties:

   o Each side assumes that the authentication and authentication
     details proferred by the remote party stay constant until
     explicitly changed (or until the TLS session is ended).

   o More stringently, each side trusts the other to send a timely
     notification if authentication or authorization details of the
     other party's end system(s) have changed.

Either of these assumptions about trust may be false if an intruder has
breached communications between a client or server and its respective
end system. And either may be false if a component is badly implemented
or configured. Implementers should take care in program construction to
avoid invalidating these trust relationships, and should document to
configuring-users the proper ways to configure the software to avoid
invalidation of these relationships.

5.5  Telnet negotation handling

There are two aspects to Telnet negotiation handling that affect the
security of the connection.  First, given the asynchronous nature
of Telnet option negotiations it is possible for a telnet client or
server to allow private data to be transmitted over a non-secure
link.  It is especially important that implementors of this telnet
option ensure that no telnet option sub-negotiations other than those
related to authentication and establishment of security take place over
an insecure connection.

The second item is related to the most common error when implementing
a telnet protocol state machine.  Most telnet implementations do not
check to ensure that the peer responds to all outstanding requests
to change states: WILL, DO, WONT, DONT.  It is important that all
telnet implementations ensure that requests for state changes are
responded to.


6    TLS Variants and Options

TLS has different versions and different ciphersuites 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.

6.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 1.0 or higher is not supported. This is permissible; however,
client implementations which negotiate SSL3.0 MUST still follow the
rules in Section 5.3 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].  SSL 2.0 MUST NOT be negotiated.

6.2    Using Kerberos V5 with TLS

If the client and server are both amenable to using Kerberos V5, then
using non-PKI authentication techniques within the confines of TLS may
be acceptable (see [TLSKERB]). Note that clients and servers are under
no obligation to support anything but the ciphersuite(s) mandated in
[TLS]. However, if implementations do implement the KRB5 authentication
as a part of TLS ciphersuite, then these implementations SHOULD support
at least the TLS_KRB5_WITH_3DES_EDE_CBC_SHA ciphersuite.

Kerberos V5 can also be securely negotiated using TELNET AUTH KRB5 after
START_TLS negotiation has completed.  This is the preferred method of
combining TLS and Kerberos V5 authentication. [AUTH-KRB5]

6.3    TLS Channel Bindings for use with TELNET AUTH mechanisms

When the Telnet AUTH option is negotiated over TLS, the authentication
option SHOULD verify the TLS channel bindings data [TLS-CB]. Doing so
provides a strong cryptographic binding between the client
authentication and the underlying TLS session.


7    Protocol Examples

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

7.1    Successful TLS negotiation

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

// typical successful opening exchange
  S: IAC DO START_TLS
  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
  S: IAC SB START_TLS FOLLOWS IAC SE
// server now readies input stream for non-Telnet, TLS-level negotiation
  C: [starts TLS-level negotiations with a ClientHello]
  [TLS transport-level negotiation ensues]
  [TLS transport-level negotiation completes with a Finished exchanged]
// either side now able to send further Telnet data or commands

7.2    Successful TLS negotiation, variation

The following protocol exchange is the typical sequence that starts TLS,
but with the twist that the (TN3270E) server is willing but not
aggressive about doing TLS; the client strongly desires doing TLS.

// typical successful opening exchange
  S: IAC DO TN3270E
  C: IAC WILL START_TLS IAC
  S: IAC DO START_TLS
  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
  S: IAC SB START_TLS FOLLOWS IAC SE
// server now readies input stream for non-Telnet, TLS-level negotiation
  C: [starts TLS-level negotiations with a ClientHello]
  [TLS transport-level negotiation ensues]
  [TLS transport-level negotiation completes with a Finished
                 exchanged]
// note that server retries negotiation of TN3270E after TLS
// is done.
  S: IAC DO TN3270E
  C: IAC WILL TN3270E
// TN3270E dialog continues....


7.3    Unsuccessful TLS negotiation

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

//typical unsuccessful opening exchange
  S: IAC DO START_TLS
  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
  S: IAC SB START_TLS FOLLOWS IAC SE
// server now readies input stream for non-Telnet, TLS-level negotiation
  C: [starts TLS-level negotiations with a ClientHello]
  [TLS transport-level negotiation ensues]
  [TLS transport-level negotiation fails with server sending
               ErrorAlert message]
  S: [TCP level disconnect]
//  server (or both) initiate TCP session disconnection

This example assumes that the server wants to do TLS, but is willing to
allow the session to proceed without TLS security; however, the client's
version of TLS does not interoperate with the server's.

//typical unsuccessful opening exchange
  S: IAC DO START_TLS
  C: IAC WILL START_TLS IAC SB START_TLS FOLLOWS IAC SE
  S: IAC SB START_TLS FOLLOWS IAC SE
// server now readies input stream for non-Telnet, TLS-level negotiation
  C: [starts TLS-level negotiations with a ClientHello]
  [TLS transport-level negotiation ensues]
  [TLS transport-level negotiation fails with server sending
               ErrorAlert message]
  S: [TCP level disconnect]
// session is dropped

7.4    Authentication via Kerberos 5 after TLS negotiation

Here's an implementation example of using Kerberos 5 to authenticate the
client after encrypting the session with TLS. Note the following
details:

   o The client strictly enforces a security policy of proposing Telnet
     AUTH first, but accepting TLS. This has the effect of producing a
     rather verbose pre-TLS negotiation sequence; however, the
     end-result is correct. A more efficient pre-TLS sequence can be
     obtained by changing the client security policy to be the same as
     the server's for this connection (and implementing policy-aware
     negotiation code in the Telnet part of the client).

     A similar efficient result can be obtained even in the absence of a
     clear client security policy if the client has cached server
     security preferences from a previous Telnet session to the same
     server.

   o The server strictly enforces a security policy of proposing TLS
     first, but falling back to Telnet AUTH.

  C: IAC WILL AUTHENTICATION
  C: IAC WILL NAWS
  C: IAC WILL TERMINAL-TYPE
  C: IAC WILL NEW-ENVIRONMENT
  S: IAC DO START_TLS
  C: IAC WILL START_TLS
  C: IAC SB START_TLS FOLLOWS IAC SE
  S: IAC DO AUTHENTICATION
  S: IAC DO NAWS
  S: IAC WILL SUPPRESS-GO-AHEAD
  S: IAC DO SUPPRESS-GO-AHEAD
  S: IAC WILL ECHO
  S: IAC DO TERMINAL-TYPE
  S: IAC DO NEW-ENVIRONMENT
  S: IAC SB AUTHENTICATION SEND
    KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ
    KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL
    KERBEROS_V5 CLIENT_TO_SERVER|ONE_WAY
    SSL CLIENT_TO_SERVER|ONE_WAY   IAC SE
  S: IAC SB TERMINAL-TYPE SEND  IAC SE
  S: IAC SB NEW-ENVIRONMENT SEND  IAC SE
  S: IAC SB START_TLS FOLLOWS  IAC SE
  [TLS - handshake starting]
  [TLS - OK]
  C: IAC WILL AUTHENTICATION
  C: IAC WILL NAWS
  C: IAC WILL TERMINAL-TYPE
  C: IAC WILL NEW-ENVIRONMENT
  <wait for outstanding negotiations>
  S: IAC DO AUTHENTICATION
  S: IAC DO NAWS
  S: IAC WILL SUPPRESS-GO-AHEAD
  C: IAC DO SUPPRESS-GO-AHEAD
  S: IAC DO SUPPRESS-GO-AHEAD
  C: IAC WILL SUPPRESS-GO-AHEAD
  S: IAC WILL ECHO
  C: IAC DO ECHO
  S: IAC DO TERMINAL-TYPE
  S: IAC DO NEW-ENVIRONMENT
  S: IAC SB AUTHENTICATION SEND
    KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL
    KERBEROS_V5 CLIENT_TO_SERVER|ONE_WAY
    IAC SE
  C: IAC SB AUTHENTICATION NAME jaltman IAC SE
  C: IAC SB AUTHENTICATION IS
    KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL AUTH
    6e 82 01 d4 30 82 01 d0 | a0 03 02 01 05 a1 03 02
    01 0e a2 07 03 05 00 20 | 00 00 00 a3 82 01 18 61
    82 01 14 30 82 01 10 a0 | 03 02 01 05 a1 10 1b 0e
    41 54 48 45 4e 41 2e 4d | 49 54 2e 45 44 55 a2 29
    30 27 a0 03 02 01 03 a1 | 20 30 1e 1b 04 68 6f 73
    74 1b 16 61 6c 6c 2d 6e | 69 67 68 74 2d 74 6f 6f
    6c 2e 6d 69 74 2e 65 64 | 75 a3 81 cb 30 81 c8 a0
    03 02 01 01 a1 03 02 01 | 10 a2 81 bb 04 81 b8 92
    25 23 ce 7a 7d dc bf 7d | 7a 53 07 17 55 3a 55 ef
    2b d5 44 7f bd f2 8e a5 | 13 69 ee e2 72 e2 10 9a
    a4 cf cb 55 3e 4a db d9 | 10 37 f4 50 be 6f 91 29
    c4 ef fe 77 ba ae b9 b7 | 5e e1 1c ed ff ff b8 f6
    b3 00 2d d9 83 1c 42 08 | bc 8b 14 aa de fa 46 39
    db 02 ed 21 79 66 4e 5d | 8a d6 f6 5a 66 10 82 00
    06 f4 cd b7 0e d4 57 99 | 89 81 f8 dc 4b 64 60 90
    75 66 d3 c9 74 27 ea 75 | d5 57 7a 7b 29 ad e1 de
    58 23 42 d8 09 f8 14 b7 | a4 67 8b 1c 86 e7 be 6f
    d8 69 66 d1 ab 8e 62 cc | a5 ee 43 02 7e 0c 16 c5
    ad 29 30 25 bc 26 98 0a | f1 3e c9 e8 14 7e 84 4e
    06 66 2c 0c f2 37 ee da | a4 81 9e 30 81 9b a0 03
    02 01 01 a2 81 93 04 81 | 90 3e d1 48 2b a3 e2 27
    90 48 35 93 d2 48 6a 80 | 6d 59 cd ab bb 94 23 99
    4c e8 02 e2 77 0e 39 e9 | e9 35 86 48 68 1b f2 94
    03 45 66 6f f2 e1 b0 f0 | 7f 78 ae ef 78 75 a8 e5
    03 47 ef 6a 08 b5 10 48 | 2a 3e f4 a4 dd 56 f9 5e
    03 4c a0 09 92 9f 22 3d | d5 5d 22 4b 9d ef e8 de
    cd 27 71 5b a2 4d 48 d3 | 85 73 0b 82 e5 22 52 4b
    b5 aa aa 6c bf aa 79 d2 | 9a b4 c2 48 3a 31 04 44
    bb d7 14 b3 2c f3 00 70 | be 04 a2 95 30 bb c2 dc
    a2 93 62 89 45 b2 64 bb | 8e
    IAC SE
  S: IAC SB TERMINAL-TYPE SEND  IAC SE
  S: IAC SB NEW-ENVIRONMENT SEND  IAC SE
  S: IAC SB AUTHENTICATION REPLY
   KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL RESPONSE
    6f 59 30 57 a0 03 02 01 | 05 a1 03 02 01 0f a2 4b
    30 49 a0 03 02 01 01 a2 | 42 04 40 29 56 c7 c0 87
    17 49 e4 87 02 d4 e1 ce | 34 de 78 a6 ae a8 cd f4
    b9 12 c4 88 29 93 f3 21 | f9 69 4e 65 73 fa 3a 6f
    70 fd 6e 18 bb 73 22 25 | d7 3b 1b e1 20 6c 45 d7
    6f 35 e3 3b 84 41 db 9b | 19 a4 44
   IAC SE
  S: IAC SB AUTHENTICATION REPLY
   KERBEROS_V5 CLIENT_TO_SERVER|MUTUAL ACCEPT "jaltman@ATHENA.MIT.EDU"
   IAC SE
  C: IAC SB TERMINAL-TYPE IS VT320 IAC SE
  C: IAC SB NEW-ENVIRONMENT IS VAR USER VALUE jaltman VAR SYSTEMTYPE \\
           VALUE WIN32 IAC SE
  C: IAC SB NAWS 162 49 IAC SE

Here are several things to note about the above example:

   o After TLS is successfully negotiated, all non-TLS Telnet settings
     are forgotten and must be renegotiated.

   o After TLS is successfully negotiated, the server offers all
     authentication types that are appropriate for a session using TLS.
     Note that the server, post TLS-negotiation, isn't offering Telnet
     ENCRYPT or AUTH SSL, since (a) it's useless to encrypt twice, and
     (b) TLS and/or SSL can be applied only once to a Telnet session.


8.  IANA Considerations

The IANA will update the Telnet Prootcol registry to reflect the
contents of this document.  In particular, IANA will document the
START_TLS option number and the FOLLOWS sub-option.


9.  Normative References

[ABNF]       D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC2235, November 1997.

[AUTH]       J. Altman, "Telnet Authentication Option",
             successor to RFC2941.
             draft-altman-telnet-rfc2941bis

[AUTH-KRB5]  J. Altman, "Telnet Authentication: Kerberos Version 5"
             successor to RFC2942
             draft-altman-telnet-rfc2942bis

[ENCRYPT]    T.Ts'o, "Telnet Encryption Option", RFC2946,
             September 2000.

[IANA]       IANA Assigned Telnet Options
             http://www.iana.org/assignments/telnet-options

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

[RFC2360]    G. Scott, Editor. "Guide for Internet Standard Writers",
             RFC2360, June 1998.

[RFC3280]    Housley, R., Ford, W., Polk, W. and D.Solo, "Internet
             Public Key Infrastructure: Part I: X.509 Certificate and
             CRL Profile", RFC3280, April 2002.

[TELNET]     J. Postel, J. Reynolds. "Telnet Protocol Specifications",
             RFC854, May 1983.

[TLS]        Tim Dierks, C. Allen. "The TLS Protocol Version 1.1",
             RFC4346, April 2006.

[TLS-CB]     J. Altman, N. Williams.  "TLS Channel Bindings",
             draft-altman-tls-channel-bindings-XX.txt

[TLSKERB]    Ari Medvinsky, Matthew Hur. "Addition of Kerberos Cipher
             Suites to Transport Layer Security (TLS)", RFC2712, October
             1999.

[TLSPSK]     Eronen, P. and H. Tschofenig.  "Pre-Shared Key Ciphersuites
             for Transport Layer Security (TLS)", RFC4279, December 2005.


10.   Informational references

[RFC927]     Brian A. Anderson. "TACACS User Identification Telnet
             Option", RFC927, December 1984


11.   Editor

  Jeffrey Altman
  Secure Endpoints Inc
  255 W 94th ST
  New York NY 10025 USA

  jaltman@secure-endpoints.com


12.  Credits

This document was originally the product of the TN3270WG and was
co-authored by Michael Boe.  The TN3270WG closed before this document
could be submitted to the IESG.  Russ Housley and Eric Rescorla provided
significant feedback during its initial publication.


Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/