NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
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
· HTTP Over TLS
· TLS extensions for AttributeCertificate based authorization
· ECC Cipher Suites For TLS
No Request For Comments
Minutes of the Transport Layer Security (tls) Working Group
Reported by Rodney Thayer rodney@sabletech.com
The TLS working group met at the 41st IETF meeting in Los Angeles. Well over 100 people attended. Win Treese, TLS Working Group Chair, moderated the meeting.
Agenda
I. Status Report
II. Elliptic Curve Cyphersuites
III. HTTP 1.0
IV. Attribute Certificates
V. HTTP 1.1
VI. New Business/Discussion
I. Status Report - Win Treese <treese@openmarket.com.
The main draft has been approved as a Proposed Standard, it is currently administratively blocked due to a reference to PKIX. This is being changed to reference X.509. Implementors are cautioned to remember that interoperability requires referring to the PKIX information on certificates. Kerberos draft is waiting for main TLS draft.
II. Elliptic Curve Cyphersuites - Tim Dierks <timd@consensus.com>
Tim presented a draft on Elliptic Curve cyphersuites, draft-ietf-tls-ecc-00.txt. Elliptic curves offer performance and size improvements over RSA and DSS. There were questions about why both ECDSA and ECNRA rather than just one. Discussion went on about this, which was eventually closed down by the chair. There are several combinations of key exchange methods, it was pointed out that this is an example of the combinatorial cyphersuite problem we chose not to solve when the TLS draft was written. There are a total of 49 cipher suites. Issues included negotiation of fields/curves and patents. The TLS protocol can't negotiate additional crypto parameters such as field/curve selection. It was observed that the servers would have to have possibly multiple certificates depending on which curves are used. There are patents involved with this. Discussion went on as to whether this draft should go on the standards track or not.
III. HTTP 1.0 over TLS - Eric Rescorola <ekr@terisa.com>
draft-ietf-tls-https-01.txt. This draft is responsible for documenting HTTPs use of TLS through describing the existing HTTP use of SSL. Discussion of HTTPs use of SSL, port 443, separate URL type (HTTPS). Issues are connection closure and endpoint identification. Regarding endpoint identification there was a discussion about what you do to get the endpoint name (the fully qualified domain name used in the certificate.) There is a complication because name wild cards are no longer part of PKIX.
IV. Attribute Certificates in TLS - Stephen Farrell <stephen.farrell@sse.ie>
draft-ietf-tls-attr-cert-00.txt. Attribute certificates to allow role-based access control and access control forwarding. This is discussed in the TLS context because you need an authenticated, secure infrastructure to support this. The content and usage of Attribute Certificates was discussed. There was discussion from the floor. There were questions regarding the set of requirements described in this draft.
V. HTTP 1.1 over TLS - Rohit Khare <khare@alumni.caltech.edu>
Rohit presented a proposal to use the HTTP/1.1 Upgrade mechanism to upgrade a connection to TLS, thus eliminating the use of a TLS port (443) and of the https:// URL type. This is a follow-up to a discussion on the TLS mailing list and elsewhere. There was considerable discussion about this. There is an IETF motivation to remove the second port effect by some mechanism such as this. Extensive discussion followed. This topic is being further discussed on the TLS applications mailing list, ietf-apps-tls@imc.org.
Future Business: Discussion about possible charter changes, getting the postponed proposals (such as Kerberos) resolved.
None Received