Subject: SASL/GSSAPI in Telnet/tn3270e

From: Chris Newman <[email-masked]>
Date: Fri, 23 Jan 1998 12:12:33 -0800 (PST)

As per the discussion at the WG in the Washington IETF, I've written a
draft proposing one way to integrate SASL and GSSAPI into telnet.  I've
sent it to the Internet-Drafts editor, but it hasn't appeared yet.

Authentication Usage Scenarios:

Use the STARTTLS option when you want to protect the session but leave the
underlying password authentication embedded in the 3270e data stream
alone.

Use the SASL/GSSAPI options when you have the ability to authenticate at
the telnet layer rather than in the embedded stream. SASL EXTERNAL would
be used for TLS client certs.  GSSAPI/KERBEROS5 would be used for Kerberos
5 sites.

The other case to consider is the medium/lightweight authentication case.
The IETF usually uses a challenge response mechanism for lightweight
authentication (e.g., SNMPv3, PPP, POP, IMAP, ACAP) -- in fact the APOP
mechanism is the only IETF full standard security protocol. Unfortunately,
Telnet/tn3270e have a threat model which makes them unsuitable for use
with the challenge-response mechanisms.  In particular, if a machine
permits remote login then the server's authentication database is
significantly more vulnerable to attack.  The One Time Password system
(RFC 2243, in particular) is probably a reasonable choice for this case.
Since there wasn't a SASL mechanism for OTP, I wrote one (which is why
this took me longer than I expected).

Mandatory mechanism choice:

The IESG/IAB gave this WG direction to select a mandatory to implement
mechanism and requested that the choice be suitable for both regular
telnet and tn3270e.

My suspicion is that the right mandatory to implement mechanism
for tn3270e is STARTTLS for encryption only with the usual passwords
embedded in the 3270e stream.  This appears to be the right choice because
it is very difficult to move the authentication step from the 3270e
data layer to the telnet layer.

Unfortunately, I don't think this is the right choice for regular telnet.
I believe most of the time it is relatively easy to move the
authentication step from the data layer to the telnet layer with regular
telnet usage (unix machine running telnet server). And when this is
possible I believe it is very desirable as it permits the use of
lightweight non-plaintext mechanisms.  In addition, regular telnet servers
and clients are largely maintained by freeware/shareware authors who would
be reluctant to implement all the complexity of TLS and deal with export
issues.  I suspect OTP would be the right mandatory to implement mechanism
for regular telnet.

Comments?

                - Chris