comments on draft-galvin-telnet-authenc-00.txt

[Bill Sommerfeld <[e-mail]>]

I) confusion of encryption vs. integrity protection for the "end
encrypt/request end encrypt" option.

I'm sure this may have occured to one or more of you, but the
following worries me:

      The sender of this command requests that the remote side stop
      encryption of the telnet data stream.  This command is advisory
      only.  This command should only be sent in an encrypted data
      stream and should be ignored if received in an unencrypted data
      stream.  See the "Implementation Rules" section for more details.

especially since the document later states

   By linking the enabling of encryption as a side effect of successful
   authentication, protection is provided against an active attacker.

This confuses encryption and integrity protection.

Typical stream ciphers provide privacy, but not integrity; they
generate a key stream which is xor'ed with or added to the plaintext.
The plaintext often does not affect the generation of the key stream.

If a stream cipher is used for encryption (which seems likely, given
the nature of telnet sessions) and known plaintext is present (e.g., a
well known banner or prompt at login time; a habitually used first
command after login), this would be vulnerable to an active attack.

Suggestions:

 1) Add a ENCRYPT_DISABLE_END flag to the modifiers; if set, the
parties should ignore all REQUEST_END_ENCRYPT and/or END_ENCRYPT
messages.

 2) State that authentication mechanisms SHOULD send an
integrity-protected copy of the auth_encrypt-related modifiers &
options offered and accepted as part of the process of authentication
to confirm that no tampering with the initial negotiation
occurred. (and fix the mechanism(s) to do this).  If any tampering
with the initial negotiation occurred, the connection should be
dropped.

 3) Clients should do something drastic (warn user and/or drop
connection) if they receive a REQUEST_END_ENCRYPT or an unsolicited
END_ENCRYPT.

 4) Allow for a mechanism-specific verifier in the request-end-encrypt
and end-encrypt messages:

	IAC SB AUTH_ENCRYPT REQUEST_END_ENCRYPT xx xx xx xx xx xx xx xx IAC SE

	IAC SB AUTH_ENCRYPT END_ENCRYPT xx xx xx xx xx xx xx xx IAC SE

which could be used to authenticate the requests in question; if the
messages don't authenticate, the user should be notified, and/or the
connection should be dropped..

II) Additional suggested UI rules:

Note that warning the user in a secure, "out of band" way that cannot
be spoofed by a compromised server may be difficult if the telnet
client runs on an ascii terminal or terminal emulator rather than
directly using a window system; in those circumstances, the switch
should probably be set to REQUIRE or PROMPT rather than WARN.

For instance, a man-in-the-middle attacker could refuse authentication
and then send output to the client which (a) erased the warning
message, (b) presented the success message.  If the display was fast
enough, or the user was not alert, the warning would be skipped.

---

If you want me to provide more detailed text to go into the document,
I'd be happy to help.

					- Bill