Minutes of December (Washington) IETF meeting for TN3270 WG. Reported by Michael Boe - -- 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.