Skip to main content

IBM's iSeries Telnet Enhancements
draft-murphy-iser-telnet-04

Revision differences

Document history

Date Rev. By Action
2012-08-22
04 (System) post-migration administrative database adjustment to the Abstain position for Russ Housley
2006-11-08
04 (System) Request for Early review by SECDIR Completed. Reviewer: Lakshminath Dondeti.
2006-11-08
04 (System) Request for Early review by SECDIR Completed. Reviewer: Jeffrey Altman.
2006-09-24
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-09-18
04 Amy Vezza IESG state changed to Approved-announcement sent
2006-09-18
04 Amy Vezza IESG has approved the document
2006-09-18
04 Amy Vezza Closed "Approve" ballot
2006-07-12
04 Ted Hardie State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Ted Hardie
2006-07-11
04 Ted Hardie
review 1

After reading some 10 or so pages of this draft, I have decided that it is "Not Ready for Publication."  I further think …
review 1

After reading some 10 or so pages of this draft, I have decided that it is "Not Ready for Publication."  I further think that the authors won't change anything, so perhaps a DNP or a publication with an IESG note as in say RFC 4285 might be appropriate.  Given all that and given that this is not an IETF WG (not even discussed in an IETF list or IETF LC'ed) product, I decided to send the review to just the three of you.

Here are some issues:

1.  Page 8 says SHA is an encryption algorithm!

2. Page 10, first para says that a combination of seeds exchanged in the clear are used to encrypt the password!  It looks like this was just a mistake, as Section 5.1 has a different description of the process.
"
In order to communicate the server random seed value to the client,
  the server will request a USERVAR name made up of a fixed part (the 8
  characters "IBMRSEED" immediately followed by an 8-byte hexadecimal
  variable part, which is the server random seed.  The client generates
  its own 8-byte random seed value, and uses both seeds to encrypt the
  password.
"
3.  Moving to that Section 5.1, the password is encrypted with DES with a password of length no more than 10 bytes!  Some protection.

4. Next up is SHA-1 with the user-id and the password as inputs that translates to

SHA-1( SHA-1(uppercase-unicode-user-id, password), serverseed, clientseed, uppercase-unicode-user-id, SEQ) )

Slightly better than the DES usage, but not much better.  The password is of course too small. While message extension attacks are possible on this construction, they might be meaningless for the purpose.  I think the birthday attack on the first hash applies though.  I was going to suggest using HMAC, but with the 64-bit key, I am not sure how much value that's going to add.  Another concern is whether the authors are open for changing their specification.

Review 2

After making a quick pass through the document it is clear that
this document needs the ability to reference the Telnet START_TLS
option that was worked on in the TN3270 working group back in the
late 90s and which was never IETF Last Called.  The TN3270 WG
fell apart after a working group last call but before the document
ever made it to the IESG.

I have updated and re-submitted the draft as

  draft-altman-telnet-starttls-00.txt

and it should be available for review next week.  Russ should be
very familiar with it since he was one of my reviewers back in 2000.

I have also re-submitted updates to the TELNET AUTH, TELNET AUTH KRB5,
and TELNET AUTH SRP RFCs which document additional security
considerations and how to combine TELNET START_TLS with either
AUTH KRB5 or AUTH SRP.

The Murphy draft does not define any new Telnet Options in order to
satisfy its protocol requirements.  Instead it abuses in a very bad
way the TELNET TERMINAL-TYPE and TELNET NEW-ENVIRONMENT option
negotiations.  The worst thing it does is use the ability of the
server to request an environment variable by name as a means of
passing a random seed value from the server to the client.  It then
uses the client's ability to send environment variables as a means
of transmitting a random seed, either an encrypted or clear-text
password, or perhaps a GSS Token to the server.

I truly hope that IBM is not shipping servers that make use of
this specification.  All of the password exchange should be
redefined as a new Telnet Auth mechanism.  The GSS-Kerberos 5
authentication as it is currently defined only permits a single
token to be sent from the client to the server.  It provides
no protection for the preceding telnet negotiations and does
not allow for a channel binding when TLS is used as recommended.

One of the Security Considerations stated in both TELNET AUTH
and TELNET START_TLS is that until the authentication completes
the client is not permitted to negotiate NEW-ENVIRONMENT or
TERMINAL-TYPE because of privacy issues and the lack of protection.
The use of NEW-ENVIRONMENT to perform authentication makes adhering
to this rule impossible.

The draft also appears to make assumptions about the behavior
of TELNET TERMINAL-TYPE and TELNET NEW-ENVIRONMENT which are
not accurate.  The draft requires an ability to know when the
client is finished negotiating the terminal type and the
environment variables.  The way this should be handled in the
Telnet protocol is that when the client is finished sending
TELNET TERMINAL-TYPE SB and TELNET NEW-ENVIRONMENT SB commands,
the client should turn off further use of the options with
IAC WONT TERMINAL-TYPE and IAC WONT NEW-ENVIRONMENT.  This
will provide the server will a well defined indication that
the client is finished sending data and it is safe for the
server to utilize the transmitted data to construct the user
session.  The way the draft is written timing considerations
can make the difference between a session that works and one
that does not.

Several years ago I outlined a GSS-API Kerberos 5 authentication
protocol for Telnet that could be used in conjunction with START_TLS
or be used standalone to provide privacy and data integrity.
I should finish writing the draft and IBM should be encouraged to
adopt it along with TELNET START_TLS.  IBM should also be encouraged
to implement their password authentication as TELNET AUTH mechanisms.
Hopefully it is not too late to prevent code based upon this
document from being deployed.
2006-07-11
04 Ted Hardie State Change Notice email list have been change to from murphyte@us.ibm.com
2006-06-27
04 Yoshiko Fong
IANA Evaluation Comments:

Upon approval of this document, the IANA will make two additions to the Terminal
Type Name registry located at:

http://www.iana.org/assignments/terminal-type-names

The two …
IANA Evaluation Comments:

Upon approval of this document, the IANA will make two additions to the Terminal
Type Name registry located at:

http://www.iana.org/assignments/terminal-type-names

The two additions are:

IBM-3812-1
IBM-5553-B01
2006-06-09
04 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-06-09
04 (System) Removed from agenda for telechat - 2006-06-08
2006-06-08
04 Sam Hartman [Ballot Position Update] New position, Abstain, has been recorded for Sam Hartman by Sam Hartman
2006-06-08
04 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Abstain from Discuss by Russ Housley
2006-06-08
04 Russ Housley [Ballot comment]
Significant issues were discovered during Security Directorate review.
2006-06-08
04 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-06-08
04 David Kessens [Ballot Position Update] Position for David Kessens has been changed to Abstain from No Objection by David Kessens
2006-06-08
04 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-06-08
04 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-06-08
04 Russ Housley [Ballot discuss]
This is a placeholder to ensure that we discuss this document on the telechat.
2006-06-08
04 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2006-06-08
04 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-06-07
04 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-06-07
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-06-07
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-06-06
04 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2006-06-06
04 Ted Hardie Ballot has been issued by Ted Hardie
2006-06-06
04 Ted Hardie Created "Approve" ballot
2006-06-06
04 (System) Ballot writeup text was added
2006-06-06
04 (System) Last call text was added
2006-06-06
04 (System) Ballot approval text was added
2006-06-06
04 Bill Fenner State Changes to IESG Evaluation from Publication Requested by Bill Fenner
2006-05-25
04 Ted Hardie Placed on agenda for telechat - 2006-06-08 by Ted Hardie
2006-05-25
04 Ted Hardie [Note]: 'Recommended for Response 1, Note 2. of RFC 3932.' added by Ted Hardie
2006-05-25
04 Ted Hardie Review comments on the substance of the document should be sent to the RFC Editor for their consideration.
2006-04-14
04 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-04-11
04 (System) New version available: draft-murphy-iser-telnet-04.txt
2005-09-08
03 (System) New version available: draft-murphy-iser-telnet-03.txt
2004-06-24
02 (System) New version available: draft-murphy-iser-telnet-02.txt
2004-01-15
01 (System) New version available: draft-murphy-iser-telnet-01.txt
2003-06-20
00 (System) New version available: draft-murphy-iser-telnet-00.txt