Subject: TN mandatory mechanizm, authentication Re: TN3270E Digest 1/

From: John Hind <[email-masked]>
Date: Mon, 26 Jan 1998 12:56:13 -0500

Chris -

  The important thing to keep in mind is that there are two authentications
involved, the client knowing the TN server identify and inferring from this the
TARGET host identity, and the target host knowing the user identity at the
client. It is not at all clear that Telnet and TN3270 have a common basis
that their respective usage community would embrace for choosing a single
mandatory mechanism for both of them.

 Lets face it, outside of the not highly used kerberos RFC there is no
server authentication in use today with Telnet (knowing for sure what server
you are talking to) and without this there is no way of protecting the
clients identity from being stolen by a third party. While client
authentication schemes exist, without server authentication, they are of
little value.

 TLS is important not simply as an encryption for a TWO WAY
authentication mechanism like KERBOROS BUT ALSO as a one way SERVER
authentication mechanism which secures other forms of client authentication
be it 3270 data stream ID/password or clear-text telnet ID/password or
some Telnet protocol challenge response scheme. This
brings up another often overlooked sticky subject - delegation in
multi-hop flows demonstrated by our TN3270 asymmetric authentication
requirement (target host authenticates person at client while client
authenticates TN server, target host is often not equal to TN server!).

 You can't choose a mandatory scheme which imposes a requirement on the
TN3270/TN5250 SNA flow between the TN server and the target HOST (that
includes forced sharing of secrets). So if we insist on one mechanism for
traditional Telnet and TN3270/TN5250 we must choose TLS TN server
authentication with encrypted data stream client authentication.

John Hind

|--------------------------------------------------------------------------------
|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
|uthentication (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

---

From: Chris Newman <[email-masked]>
Date: Mon, 26 Jan 1998 09:57:37 -0800 (PST)

> authentication with encrypted data stream client authentication.

I think we're basically agreeing.  I was proposing that TLS TN server
authentication + full strength encryption appeared to be the best choice
as a mandatory to implement mechanism for TN3270 and was speculating that
it's not the best choice for regular telnet.

                - Chris