NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 28-Oct-97
Chair(s):
Win Treese <treese@openmarket.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-tls@consensus.com
To Subscribe: ietf-tls-request@consensus.com
Archive: http://www.imc.org/ietf-tls/mail-archive
Description of Working Group:
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:
May 96 |
|
Agreement on charter and issues in current draft. |
Jul 96 |
|
Final draft for Secure Transport Layer Protocol ('STLP') |
Nov 96 |
|
Working group 'Last Call' |
Dec 96 |
|
Submit to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
· The TLS Protocol Version 1.0
No Request For Comments
Minutes of the Transport Layer Security (TLS) Working Group
Reported by Win Treese <treese@OpenMarket.com> (WG Chair), based in part on notes by Chris Allen <ChristopherA@Consensus.com>.
Mailing list: ietf-tls@consensus.com
Web site: http://www.consensus.com/ietf-tls
Win Treese called the meeting to order, with the following agenda:
I. Status
II. Old business: ports, patents, IANA registration
III. Other drafts before the WG: Kerberos, SSL Tunneling Proxy
IV. Applications using TLS
V. Description of server-gated crypto (Dierks)
VI. Implementation notes
VII. Next Steps
VIII. Summary of Actions
I. Status
The TLS draft has been moved by the IESG to Proposed Standard, and it will be issued as an RFC shortly. Congratulations to everyone on the working group for contributing to this milestone.
II. Old Business
Ports. Over time, there has been much discussion about whether or not TLS applications should use different ports from their non-TLS relatives. This decision must be made for each application individually, so the issue is out of scope for the working group. As it turns out, many applications are negotiating TLS within their own protocols.
Patents. There has been some concern about a patent for SSL recently issued to Netscape. Netscape has provided a statement that is appended to the TLS specification. In general terms, Netscape is granting a royalty-free patent license to anyone who implements TLS, as long as they do not assert that Netscape's implementation infringes on any patents they hold. See the forthcoming RFC for the precise statement.
IANA registration of ciphersuites and other numbers. Based on advice from several sources, new TLS ciphersuites and similar identifiers will not be registered through the IANA. Rather, they will be the subject of new documents, which may be put on the standards track as appropriate.
III. Other Drafts
Two other drafts are before the working group:
Kerberos ciphersuites for TLS. This document has been on hold until the main draft moved to Proposed Standard. Now that it has, the Kerberos document will be sent out for last call in the working group as soon as an updated revision is available.
SSL Tunneling for HTTP. This document is not formally before the working group, but it might make sense for the WG to adopt it. Win Treese will discuss this with the author.
IV. Applications
Quite a few application protocols are specifying TLS. These include SOCKS, LDAP, FTP, SMTP, IMAP4+POP3, and PPP EAP. WebDAV and IPP are in progress and planning to use TLS. At this point, there is no draft specifying the use of TLS with HTTP (for any version of HTTP). Eric Rescorla volunteered to write a draft describing the current usage of HTTP 1.0 over TLS, and we will try to find one for HTTP 1.1 as well.
Paul Hoffman noted that LDAP with TLS is currently before IESG, with SMTP over TLS and IMAP4+POP3 likely to follow.
Bob Morgan, author of LDAP over TLS, is interested in hearing from WG members about the way LDAP uses TLS.
Carl-Uno Manros, co-chair of the IPP working group, said that IPP has all printing related issues done, but still are wobbly on exact use of TLS. Issues are using insecure way. They wanted to use null_null_null, but this is not allowed. They are packaging IPP it over http.
Micheal Bowe said the TN3270 working group has a problem: if a suitable ciphersuite can't be negotiated, the TCP connection must be dropped. A response from the floor was that this was changed in the latest TLS draft. Only TLS has to be dropped, not the TCP connection.
Discussions of TLS applications take place on the mailing list ietf-apps-tls@imc.org.
V. Server-Gated Crypto
Tim Dierks described a mechanism called by some "server-gated cryptography." Variations of this are used by both Netscape and Microsoft. The idea is that a client may be exported from the US with both strong and export-grade cryptography, but the strong cryptography is enabled only if the server has a particular kind of certificate.
In both SSL and TLS, the client must drop the connection and restart the handshake once it knows that it can use additional ciphers. It would simplify things if the client can simply send a new hello message.
A more detailed proposal will be forthcoming.
VI. TLS Implementation Warning
Tim Dierks also warned implementors about the following problem so they would not repeat it:
The definition of an SSL/TLS vector <1..65335> is:
Hi Lo Contents
|LM|LL| | | | ...
In all SSL implementations, the client key exchange field is miscoded in RSA and RSA_EXPORT key exchanges: it is missing the length field. Please avoid this error in TLS implementations.
VII. Next Steps
Chris Allen noted that the applications protocols are, in essence, our customers now, and we should talk to them often.
There were a number of proposed changes discussed in Memphis (two meetings ago), but we have not seen detailed proposals or new drafts to follow up on them. There is continued interest in combining IPSec key exchange mechanisms with TLS.
Thanks to Chris Allen for taking the notes during the WG meeting.
None Received