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

Versions: 00 01 02 03 04 05 06

Internet Engineering Task Force                             Michael Boe
INTERNET-DRAFT draft-ietf-tn3270e-telnet-tls-03.txt         Cisco Systems
expires March 2001
                                                            October, 1999

                        TLS-based Telnet Security

Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. 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."

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.

Copyright Notice
Copyright (C) The Internet Society (1998, 1999). All Rights Reserved.

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

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
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.

Changes since -02 Draft
   o Clarify server actions in response to client initiating the TLS
     negotiation.

   o Replace the parochial term "mainframe" with "application-server."

   o Nuke explicit references to RFC1416, since there's a new RFC in the
     works for this and the reference isn't normative anyway.

   o Use dNSName language similar to that used in the most recent HTTP TLS
     draft.

   o Delete beginning paragraph describing server-authentication in TLS.
     Unclear and possibly wrong.

   o Delete explicit references to SASL, since we don't actually describe
     ways of using SASL.

   o Add section describing interaction between AUTH and STARTTLS option
     negotiations.

Changes since -01 Draft
   o Drop possibility of a continuing a Telnet session if the TLS
     negotiation fails.

   o Assert that server sending DO STARTTLS must be willing to negotiate
     a TLS session

   o Change SHOULD to MUST with respect to a server requesting a client
     certificate.

   o Add paragraph on commonName to section on check of X.509
     certificate.

   o Sharpen language concerning notification of possible
     server-certificate mismatch.

   o drop place-holder section on Kerberos 5 security; replace with
     section on non-PKI-based authentication (after TLS negotiation).

Michael Boe                                                           [Page
2]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
   o Prohibit fallback to SSL 2.0.

   o Give more details about how authentication-after-TLS-negotiation
     can be achieved.

   o Simplify post-TLS Telnet negotiation state-assumptions by resetting
     them to initial-state.

Changes since -00 Draft
   o Add local authentication/authorization operational model.

   o Change behavior of Telnet machine to reset at start of TLS
     negotiation.

   o Insert narrative questioning the utility of allowing continuation of
     Telnet session after TLS has ended.

   o change examples to reflect the above changes.

   o Fix several typos.

Michael Boe                                                           [Page
3]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
Contents

1    Introduction
6
2    Telnet STARTTLS Option and Subnegotiation
8

     2.1     Abnormal Negotiation Failure    .    .    .    .    .    .
9

     2.2     Assigned Values for STARTTLS Negotiation    .    .    .   .
9
3    Telnet Authentication and Authorization
10
4    TLS, Authentication and Authorization
11

     4.1     Authentication of the remote party       .    .    .    .
14

     4.2     PKI-based Authentication and certificate extensions
15

     4.3     Pre-TLS Authentication      .    .    .    .    .    .    .
15
5    Security
16

     5.1     Authentication of the Server by the Client   .    .    .
16

          5.1.1     PKI-based certificate processing      .    .    .
16

     5.2     Non-PKI-based Authentication of client or server     .
17

     5.3     Display of security levels      .    .    .    .    .    .
17

     5.4     Trust Relationships and Implications    .    .    .    .
17
6    TLS Variants and Options
18

     6.1     Support of previous versions of TLS      .    .    .    .
18

     6.2     Using Kerberos V5 with TLS       .    .    .    .    .    .
18
7    Protocol Examples
19

Michael Boe                                                           [Page
4]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
     7.1     Successful TLS negotiation      .    .    .    .    .    .
19

     7.2     Successful TLS negotiation, variation   .    .    .    .
19

     7.3     Unsuccessful TLS negotiation    .    .    .    .    .    .
20

     7.4     Authentication via Kerberos 4 after TLS negotiation
21

Michael Boe                                                           [Page
5]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
1    Introduction
We are interested in addressing the interaction between the Telnet
client and server that will support this secure requirement with the
knowledge that this is only 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 TN 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. We make the assumption here that there is a trust
relationship and appropriate protection to support that relationship
between the TN 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 to control access
to information. We further make the assumption that the path between the
end user and the client is protected.

To hold up the Telnet part of the overall secure path between the user
and the application-server, the Telnet data stream must appear
unintelligible to a third party. This is done by creating 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 specialized new protocol which accomplishes these goals we
instead have chosen to use existing protocols with certain constraints.

One such existing protocol is the TLS protocol (formerly known as SSL).
And the Telnet [TELNET ] application protocol can certainly benefit from
the use of TLS. Other security mechanisms have been used in Telnet via
the AUTH and ENCRYPT options, but 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.

TLS is used to provide the following:

   o creation and refresh of a shared secret;

   o negotiation and execution of data encryption and optional

Michael Boe                                                           [Page
6]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
     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 offer the possibility of the client
providing separate credentials for authorization than were presented for
authentication. It is expect that other RFCs will be produced describing
how other authentication mechanisms can be used in conjunction with TLS.

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 unstandardized method.

This document 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.

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 [ANBF ].

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

Michael Boe                                                           [Page
7]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
2    Telnet STARTTLS Option and Subnegotiation
The STARTTLS option is an asymmetric option, with only the server side
being able to send IAC DO STARTTLS. The client may initiate by sending
IAC WILL STARTTLS. There are some more rules due to the need to clear the
link of data (or to synchronize the link). 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 STARTTLS with either IAC WONT
     STARTTLS or IAC WILL STARTTLS (if it hasn't already done so). An
     affirmative response MUST be followed immediately by IAC SB STARTTLS
     FOLLOWS IAC SE. If the client sends the affirmative response, it
     must then not initiate any further Telnet options or subnegotiations
     except for the STARTTLS subnegotiation until after the TLS
     negotiation has completed.

 2.  If the client initiates by sending IAC WILL STARTTLS, the server
     SHOULD send the IAC DO STARTTLS as soon as practical.

 3.  The server SHOULD NOT send any more Telnet data or commands after
     sending IAC DO STARTTLS except in response to client Telnet options
     received until after it receives either a negative response from the
     client (IAC WONT STARTTLS) or the affirmative (both IAC WILL
     STARTTLS and followed eventually by IAC SB STARTTLS FOLLOWS IAC SE).
     If the client's STARTTLS option response is negative, the server is
     free to again send Telnet data or commands. If the client's response
     is affirmative, then the server MUST send only IAC SB STARTTLS
     FOLLOWS IAC SE. If the server sends IAC SB STARTTLS FOLLOWS IAC SE,
     then the server MUST also arrange at this time, for the normal Telnet
     byte-stuff/destuff processing to be turned off for the duration of
     the TLS negotiation.

 4.  If both STARTTLS and AUTH are offered, STARTTLS MUST be sent first
     and take precedence if both are agreed to. AUTH may be renegotiated
     after successful establishment of the TLS session if end-user
     authentication is desired.

 5.  The client, upon receipt of the server's IAC SB STARTTLS FOLLOWS IAC
     SE, MUST also arrange for normal Telnet byte-stuff/destuff
     processing to be turned off for the duration of the TLS negotiation.
     It MUST then enter into TLS negotiation by sending the TLS
     ClientHello message.

Here's a breakdown of the Telnet command phrases defined in this
document:

Michael Boe                                                           [Page
8]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
S: IAC DO STARTTLS--   Sent only by server. Indicates that server strongly
     desires that the client enter into TLS negotiations.

C: IAC WILL STARTTLS--    Sent only by client. Indicates that client
     strongly desires that the server enter into TLS negotiations.

S: IAC DONT STARTTLS--    Sent only by the server. Indicates that the
     server is not willing to enter into TLS negotations.

C: IAC WONT STARTTLS--    Sent only by the client. Indicates that the
     client is not willing to enter into TLS negotiations.

C: IAC SB STARTTLS FOLLOWS IAC SE--     When sent by the client, this
     indicates that the client is preparing for TLS negotiations, and
     that the next thing sent by the client will be the TLS ClientHello.
     Also indicates that the client has reset its Telnet state.

S: IAC SB STARTTLS FOLLOWS IAC SE--     When sent by the server, this
     indicates that the server has prepared to receive the TLS
     ClientHello from the client. Also indicates that the server has
     reset its Telnet state.

2.1    Abnormal 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 TLS
upon reconnecting after a TLS negotiation failure.

2.2    Assigned Values for STARTTLS Negotiation

The assigned value of the Telnet STARTTLS option octet is 46. The
assigned value of the FOLLOWS subnegotiation octet is 1. In ABNF, this
is:

    STARTTLS = %d46
    FOLLOWS  = %d1

Michael Boe                                                           [Page
9]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
3    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 to how Client and
     Server can sucessfully exchange 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).
Michael Boe                                                          [Page
10]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
4    TLS, Authentication and Authorization
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 (e.g.[TLSKERB ] or Telnet 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 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.

[Author's note: I dislike providing state models of how local systems
should behave in relation to a wire protocol; it seems to me that such
models often do more harm than good when describing a wire protocol. The
model often misrepresents reality, and/or makes unnecessarily limiting
assumptions about implementation behavior. However, the alternative
methods of explanation seemed even less useful in this case....]

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

`unauthenticated'    The local party has not received any credentials
     offered by the remote. 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 STARTTLS 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.

Michael Boe                                                          [Page
11]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
     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

Michael Boe                                                          [Page
12]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
     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
-------+--------------------------------------------

Michael Boe                                                          [Page
13]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
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 remote party

If TLS has been successfully negotiated, the client will have the
server's certificate. This indicates that the server's identity can be
verified. Client implementations MUST always verify the server identity
as part of TLS processing and fail the connection if such verification
fails, unless Telnet AUTH will be used to perform mutual authentication
and verification of the session key. See Section 5.1 for a general
discussion of the server authentication apropos Telnet clients.

The server, however, may not have the client's identity (verified or
not). This is because the client need not provide a certificate during
the TLS exchange. Or it may be server site policy not to use the identity
so provided. In any case, 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 after TLS has been negotiated, it MUST occur before any
non-authentication-related Telnet interactions take place on the link
after TLS starts. 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

Michael Boe                                                          [Page
14]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
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 separate to the TLS
mechanism.

4.2    PKI-based Authentication and certificate extensions

When PKI authentication is used no special X.509 certificate extensions
will be require but a client or server may choose to support an extension
if found. For example, they may use a contained certificate revocation
URL extension if provided. The intent is to allow sharing of
certificates with other services on the same host, for example, a Telnet
server might use the same certificate to identify itself that a
co-located WEB server uses. The method of sharing certificates is
outside the scope of this document.

An X.509 certificate received by a client may include the
`subjectAltName' extension. If this extension is present and contains a
`dNSName' object, then the client MUST be used as the identity.
Otherwise, the (most specific) Common Name field in the Subject field fo
the certificate MUST be used. Note that the Common Name field technique
is currently used, it is deprecated.

If the subjectAltName extension is not present, then the client may use
the commonName field as long as the contents of the field are interpreted
as fully qualified domain names.

4.3    Pre-TLS Authentication

It could be that the server had moved the Telnet connection to the
authenticated state sometime previous to the negotiation of TLS. If this
is the case, then the server MUST NOT use the credentials proffered by
the client during the TLS negotiations for authorization of that client.
The server should, of course, verify the client's TLS-proffered
credentials.

Michael Boe                                                          [Page
15]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
Note that such an authenticated state could not have resulted from
previous data exchanged on this Telnet session, and must have been
authenticated via some other means.

5    Security
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    Authentication of the Server by the Client

How the client can verify the server's proferred identity varies
according to the key-exchange algorithm used in the selected TLS
cipher-suite. However, it's important for the client to follow good
security practice in verifying the proffered identity of the server.

5.1.1   PKI-based certificate processing

The verification of the server's certificate by the client MUST include,
but isn't limited to, the verification of the signature certificate
chain to the point where the a signature in that chain uses a known good
signing certificate in the clients local key chain. 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 no match is found 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.

Michael Boe                                                          [Page
16]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
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    Non-PKI-based Authentication of client or server

Authentication of the client (or further mutual authentication between
client and server) can be accomplished via non-PKI means, too.
Implementors should be careful to remember that authentication must
occur after successful TLS session negotiation where the shared secret
is verified. Further, the timing of the authentication MUST be as per
Section  4.

Practically speaking, this means that non-TLS authentication MUST
immediately follow the TLS negotiation. See  7.4 for an example of how
this can work.

5.3    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 and
     the fact that such a cipher-suite may compromise security.

   o The Telnet endpoints SHOULD log the exact choice of cipher-suite 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:

Michael Boe                                                          [Page
17]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
   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.

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

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
3.1 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 ]. Negotiating SSL 2.0 MUST NOT be attempted.

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

Michael Boe                                                          [Page
18]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
be acceptable (see [TLSKERB ]). Note that clients and servers are under
no obligation to support anything but the cipher-suite(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.

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 STARTTLS
  C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE
  S: IAC SB STARTTLS 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 STARTTLS IAC
  S: IAC DO STARTTLS
  C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE
  S: IAC SB STARTTLS FOLLOWS IAC SE

Michael Boe                                                          [Page
19]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
// 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 STARTTLS
  C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE
  S: IAC SB STARTTLS 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 STARTTLS
  C: IAC WILL STARTTLS IAC SB STARTTLS FOLLOWS IAC SE
  S: IAC SB STARTTLS 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

Michael Boe                                                          [Page
20]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
               ErrorAlert message]
  S: [TCP level disconnect]
// session is dropped

7.4    Authentication via Kerberos 4 after TLS negotiation

Here's an implementation example of using Kerberos 4 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 STARTTLS
  C: IAC WILL STARTTLS
  C: IAC SB STARTTLS 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_V4 CLIENT_TO_SERVER|MUTUAL|ENCRYPT_REQ
    KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL

Michael Boe                                                          [Page
21]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
    KERBEROS_V4 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 STARTTLS 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_V4 CLIENT_TO_SERVER|MUTUAL
    KERBEROS_V4 CLIENT_TO_SERVER|ONE_WAY   IAC SE
  C: IAC SB AUTHENTICATION NAME jaltman IAC SE
  C: IAC SB AUTHENTICATION IS
    KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL AUTH
    04 07 0B "CC.COLUMBIA.EDU" 00 "8(" 0D 9E 9F AB A0 "L" 15 8F A6
    ED "x" 19 F8 0C "wa" CA "z`" 1A E2 B8 "Y" B0 8E "KkK" C6 AA "<" FF
    FF 98 89 "|" 90 AC DF 13 "2" FC 8E 97 F7 BD AE "e" 07 82 "n" 19 "v"
    7F 10 C1 12 B0 C6 "|" FA BB "s1Y" FF FF 10 B5 14 B3 "(" BC 86 "`"
    D2 "z" AB "Qp" C4 "7" AB "]8" 8A 83 B7 "j" E6 "IK" DE "|YIVN"
    IAC SE
  S: IAC SB TERMINAL-TYPE SEND  IAC SE
  S: IAC SB NEW-ENVIRONMENT SEND  IAC SE
  S: IAC SB AUTHENTICATION REPLY
   KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL ACCEPT  IAC SE
  C: IAC SB AUTHENTICATION IS
   KERBEROS_V4 CLIENT|MUTUAL CHALLENGE "[" BE B7 96 "j" 92 09 "~" IAC SE
  S: IAC SB AUTHENTICATION REPLY
   KERBEROS_V4 CLIENT_TO_SERVER|MUTUAL RESPONSE "df" B0 D6 "vR_/"  IAC SE
<no outstanding negotiations>
  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

Michael Boe                                                          [Page
22]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
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 and perhaps dangerous to
     encrypt twice, and (b) TLS and/or SSL can be applied only once to a
     Telnet session.

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

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

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

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

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

[TLS]        Tim Dierks, C. Allen. "The TLS Protocol", RFC2246, January
             1999.

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

Author's Address
  Michael Boe
  Cisco Systems Inc.
  170 West Tasman Drive
  San Jose, CA 95134

  Email: Michael Boe <mboe@cisco.com>

Michael Boe                                                          [Page
23]

I-D draft-ietf-tn3270e-telnet-tls-03TLS-based Telnet Security    October,
1999
Full Copyright Statement
Copyright (c) The Internet Society (1998, 1999). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of develop- ing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.

Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.

Michael Boe                                                          [Page
24]


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