Minutes of December (Washington) IETF meeting for TN3270 WG. Reported
by Michael Boe <mboe@cisco.com>
- -- intro/old business
* Ed: RFC1647 status: IESG needs statement of interoperability, then
we
can move it to Draft Standard status.
* LU6.2: IBM committed to provide LU6.2 Informational RFC...they
will be posting this by the end of the week. Reckons that this will be
"minimal" spec to allow LU6.2 flow.
- -- MIBS (Configuration MIB [was "base" MIB]):
* Bob: reviewed by Randy Presuhn. Comments were:
o several tables support remote configuration; a way of doing
multiple-server updates (ie test-and-update object).
o the indexing problem: different order, we use enum/binary
objects instead of full OIDs or transport-domains.
* updated drafts out by beginning of January...to be submitted to
IESG by end of January.
* changed anchor points of the MIB to snanauMIB {8,9}.
* added tn370eSnaMapPrimaryLuNameobject.
* Added various TCP connection objects, including a ClientId.
The nature of ClientId needs some words around.
* input needed on ClientId enum types in the MIB.
* need to make MIB IANA-registration compliant for the ClientID
enum types.
* changed Miscellaneous category to be in own class (ProxyClient).
The ProxyClient narrative description also needs some words to
properly describe.
- -- MIB (Response-Time MIB)
* "responses" or "timing-mark" (TN3270-compatible).
- -- BID/keyboard-restore issue (Roger Erickson):
* explains both the BID and keyboard-restore problem
* add FUNCTION: Contention Resolution (0x5)
* TN3270E header has a byte that is only used for printer error
recovery....so proposal is to use that byte for different purposes
for screen sessions. call this SDI.
* the keyboard-restore problem never occurs on printers.
* on BID: use the RESPONSES mechanism to carry info.
- -- Byte-doubling and Flush (Thomas Butts from OCS)
* add a TN3270E FUNCTION to suppress byte-doubling.
* add a new TN3270E FUNCTION to flush datastream at truncated.
* issue over whether or not to use TELNET BREAK key.
- -- FMH & Sense Codes:
* Support IPDS and fancy print jobs
* Transport SNA Sense codes between Client and Server.
* Open issue: OIA codes overlap with SNA sense codes. Do we need
both?
- -- Security
* RFC1416 Authenticate parms could be used; or a SASL profile
could be proposed. Chris Newman volunteers to address the SASL issue.
* Inline Negotiation appears to be the only way to go. Bob Moskovitz
claims that IANA/IESG will not allow a standard to move forward that
causes port-explosion. Others agree. Chris Newman references the
URL schema problem (eg. telnet:,telnets,tn3270,tn3270s).
* The question was raised: why not use TLS authentication instead
of encryption? After much discussion (some of which is broken out
separately below), consensus was reached that TLS of itself does not
provide all the authentication mechanisms that customers will want to
use. Specifically:
o The WG should examine the possibility of defining a SASL
profile for Telnet.
o Corporate security infrastructures are myriad in variety and
infrastructure reform is slow. Examples given were Kerberos V4,
Kerberos V5 (and NT 5.0), NT domain, RACF login/acct/password, etc.
o Some of the authentication mechanisms are able to be used
with TLS; others are not. Kerberos V5 is an example of
authentication that can be built into TLS; straight RACF
login/acct/password cannot be built into TLS.
o Some authentication mechanisms are inherently "weak."
However, they are useful (RACF springs to mind). WG will angle to
allow these weak authentication mechanisms to be used by ONLY allowing
them to be used after strong encryption (128-bit) is already
protecting the session.
* Ari Medvinsky from CyberSafe talked about the I-D which is
being moved to proposed standard that allows KRB5 to be used as a TLS
authentication mechanism. Proposed that KRB5 be one of the mandated
Position with GSS-API and manageability, for the reasons given below:
- performance
- Microsoft support in NT5.0
* Various points were made apropos different authentication
mechanisms:
- different mechanism require different infrastructures. For
example, Kerberos requires a KDC.
* GSSAPI was brought up as a method of doing security instead of
TLS. It was explained that the WG chose TLS because of widespread
deployment and understanding of its close ancestor, SSL. Also, the WG
needed deployable solutions that work with firewalls (printers were
brought up as an example of things that need good proxy & firewall
support).
- -- Service Location:
* Three proposals were discussed. Some highlights of the
operation, strengths and weaknesses of each approach were mentioned:
o SRVLOC protocol:
Pros:
- improved interoperability among servers
Cons:
- lack of deployment experience;
- uses multicast (not well deployed right now,
and could be problematic for extranet use);
- the SCOPE mechanism doesn't scale (and has recently been
changed). The SCOPE mechanism needs to be re-examined.
o Dynamic DNS: works by making server attributes into DNS names.
Pros:
- well known & deployed distribution architecture;
- improved interoperability among servers
Cons:
- may be a political hot potato. Abuse of the intent of DNS?
- limit of 255 octets per name.
o HTTP Redirection: works by querying an HTTP server to find
out which server to go to:
Pros:
- simple to understand and deploy "in the small."
Cons:
- Requires a whole new HTTP connection before the TN3270
connection can begin.
- backend protocol among servers and HTTP servers would need
definition.
* Various points made during service location discussion:
o LDAP looks pretty similar (a superset?) in power to SRVLOC.
Have we investigated using straight LDAP to do this?
o Are other groups working on similar HTTP redirection
mechanism? [answer is: "not to our knowledge."]
- -- TN5250 Standardization Progress:
* first draft expected late January.