NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Win Treese <treese@openmarket.com>
Jeffrey Schiller <jis@mit.edu>
General Discussion:ietf-tls@consensus.com
To Subscribe: ietf-tls-request@consensus.com
Archive: http://www.imc.org/ietf-tls/mail-archive
Note: This Working Group is jointly chartered by the Transport Area. The Transport Area Director: Allison Mankin <mankin@isi.edu
Several methods of providing a secure and authenticated channel between hosts on the Internet above the transport layer have appeared. The objective of this proposed working group is to write standards track RFC(s) for protocols using the currently available Internet drafts as a basis. The SSL, PCT and SSH protocols are examples of mechanisms of establishing a secure channel for general purpose or special purpose Internet applications running over a reliable transport, usually TCP.
The TLS working group is a focused effort on providing security features at the transport layer, rather than general purpose security and key management mechanisms. The standard track protocol specification will provide methods for implementing privacy, authentication, and integrity above the transport layer.
The work currently under way in the area of secure IP is outside the scope of this working group. Also, general authentication mechanism discussions are outside the focus of this group. However, best efforts will be made to utilize as much as possible of the already existing technologies and methodologies in the IETF and other places to solve common problems, such as key management.
The group may also produce an informational RFC to describe conventions for the interface to a Socket (or transport) layer secure library to build specific applications as well as TCP port number conventions for running secure versions of network applications.
Goals and Milestones:
· The SSL Protocol Version 3.0
· SSH Transport Layer Protocol
· Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
· Addition of Shared Key Authentication to Transport Layer Security (TLS)
· Modifications to the SSL protocol for TLS
· The TLS Protocol Version 1.0
Minutes of the Transport Layer Security (TLS) Working Group
Reported by: Win Treese and Christopher Allen
The TLS Working Group met during the 38th IETF meeting in Memphis, Tennessee, on April 9, 1997. The meeting was chaired by Win Treese (treese@OpenMarket.com).
The Internet Draft for TLS 1.0 is in Last Call for Proposed Standard with the IESG. The comment period closes April 25. The chair commended Tim Dierks and Christopher Allen for their work on the draft.Tim Dierks summarized some minor changes for the current draft to be incorporated into the final version:
· The vendor ID string was removed for lack of consensus.
· A new construction for the PRF (as previously noted on the mailing list).
· PRF will also be used for Finish message.
An objection was raised of using MD5 since there are now some doubts about how good it is. Ran Canetti noted that the construction does not require strong collision-randomness. Dan Simon added that there are no known attacks against this function.
Tim then discussed specifying additional cipher suites in additional documents, including the specification for bulk encryption, hashes, key exchange, and compression. There have been some suggestions to share values with other groups, like PPP and IPSEC; these will be pursued off-line.
It has also been proposed that new certificate types can be defined by adding additional cipher suites, but no agreement was reached on this approach.
There was some discussion of using a truncated PRF in the Finish messages, but there are no changes at this time.
We discussed whether or not the TLS specification should require a minimum set of cipher suites for conforming implementations. One difficulty of this is that it would either require weak cipher suites to enable exportable implementations, or make it impossible to export conforming implementations. It was suggested that any minimum cipher specs required for particular applications using TLs could be specified in "XXX protocol over TLS" documents such as "HTTP over TLS." The group agreed not to add any minimum requirements at this time.
There were no objections to proceeding through IESG last call, with the changes described by Tim Dierks.
Rodney Thayer (thayer@sabletech.com) summarized some issues from the mailing list as potential work items going forward:
- MAC, Encryption schemes, new schemes
- Shared Key Authentication, PGP, non-X.509 certificates, SPKI
· Relationship to other IETF work
· Interoperability requirements
· Interface and service definitions
- SSH, port mapping, immediate "customer needs" for using
· Enhancements to handshake protocol
These items were presented as possible work items; no decisions were made on particular items.
III. Short Presentations on Proposed Modifications
John Wilson (Intel) discussed the use of TLS for Internet Telephony and Conferencing. ITU H.323 (protocol for Internet telephony) wants to use TLS. The key issues causing problems with TLS are end-to-end trust relationship with a proxy in the center, and a lack of symmetry with certificate discovery. The proposed fix is to make the initial handshake symmetric. Dan Simon noted that reversing the client/server relationship could be used as a temporary fix for this particular application.
Ran Canetti (IBM) described some possible changes to TLS that incorporate some of the ideas from ISAKMP. These include making the RSA-encryption mode two-directional, key exchange that is anonymous for eavesdroppers, perfect forward secrecy for resuming sessions, and PRF negotiation. There was separate discussion about making TLS work well with ISAKMP and other IPSEC work so it may or may not be worthwhile to add those changes.
Matt Hur (CyberSafe) described a proposal to add Kerberos as a cipher suite for TLS. The group agreed to consider the document for the standards track. A reference implementation is available at ftp://prospero.isi.edu/pub/ssl-kerb.
There was some discussion of putting registering the identifiers for the Kerberos cipher suites into the TLS draft, but we decided not to do so.
Ned Smith (Intel) proposed a way to incorporate non-X509 certificates into the current protocol by overloading current fields. Adding such support seems like a good idea for the next version, where it might be done more cleanly.
Paul Hoffman (Internet Mail Consortium) described his proposed implementation of SMTP over TLS using an ESMTP extension to negotiate TLS, rather than using a different port.
John Gardner described two alternative approaches to layering SASL on TLS. The two are not completely compatible, but no TLS changes were proposed at this time. For more discussion, join the SASL mailing list:
ietf-sasl-request@imc.org, or see the web page http://www.imc.org/ietf-sasl
Tatu Ylonen presented some ideas for changing TLS to make it possible to use TLS as the transport security layer for SSH. SSH needs forward secrecy, more encryption ciphers, and compression, among other proposed changes. These will be discussed in more detail on the mailing list.
Treese summarized the work items for continued discussion:
· Moving forward on the Kerberos cipher suite draft
· Investigating how to benefit from IPSEC and other security area working groups.
· Shared key authentication (which was not discussed much in the meeting, but had previously been deferred)
· Support for non-X509 certificates
· Making the initial handshake symmetric
· Proposed changes to work better with SSH
· IANA registration for cipher suites