2.6.12 Transport Layer Security (tls)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 30-Oct-00

Chair(s):

Win Treese <treese@openmarket.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ietf-tls@lists.certicom.com
To Subscribe: ietf-tls-request@lists.certicom.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

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:

Done

  

Agreement on charter and issues in current draft.

Done

  

Final draft for Secure Transport Layer Protocol ('STLP')

Done

  

Working group 'Last Call'

Done

  

Submit to IESG for consideration as a Proposed Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

RFC2246

PS

The TLS Protocol Version 1.0

RFC2712

PS

Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)

RFC2817

PS

Upgrading to TLS Within HTTP/1.1

RFC2818

 

HTTP Over TLS

Current Meeting Report

Minutes from TLS Working Group
49th IETF, 12 December 2000

The TLS working group met in a one-hour session at the 49th IETF in San Diego.
The agenda was:

* Discussion of handling ciphersuite proposals
* Presentation on Kerberos ciphersuite revisions
* Discussion of AES ciphersuite proposals
* Presentation on TLS extension proposal

In general, the working group needs to adopt some guidelines for how new applications for ciphersuites are handled. The IANA originally rejected the idea of managing the ciphersuites, but Win Treese will revisit the question with them.

Matt Hur of Cisco presented proposed revisions to the Kerberos cipher suites (draft-ietf-tls-kerb-00.txt). The specification details need work, and Eric Rescorla volunteered to help Matt with them.

The AES (draft-ietf-tls-ciphersuite-02.txt) ciphersuites were discussed. The general consensus of the group was that the draft is acceptable, with two changes:

1. There should be no mandatory specification in this document
2. There should not be a specification for 192-bit keys, unless complying with the forthcoming Federal Information Processing Specification (FIPS) would require it.

John Linn of RSA presented a proposal (draft-ietf-tls-wireless-00.txt) for an extension mechanism and some specific extensions inspired by work with mobile and wireless devices. Some specific comments on the draft have been taken back to the authors.

Slides

None received.