2.6.2 Authenticated Firewall Traversal (aft)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 15-Jun-99


Marcus Leech <mleech@nortel.ca>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:aft@socks.nec.com
To Subscribe: aft-request@socks.nec.com
Archive: http://www.socks.nec.com/aftmail/

Description of Working Group:

The goal of the Authenticated Firewall Traversal Working Group is to specify a protocol to address the issue of application-layer support for firewall traversal. The working group intends to specify a traversal protocol supporting both TCP and UDP applications with a general framework for authentication of the firewall traversal. To promote interoperability, the group will also propose a base authentication technique for use within the general authentication framework.

The output of the group will consist of a standards-track RFC(s) describing the traversal protocol, the base authentication methods and a reference implementation of the protocol, and base authentication methods. The working group will start with the SOCKS system described by David Koblas in his paper presented at the 1992 Usenix Security Symposium.

Goals and Milestones:

Oct 94


Publish sample implementation for UNIX.



Issue Internet-Draft on V5 SOCKS protocol.

Nov 94


Publish sample implementation for UNIX.



Issue Internet-Draft on SOCKS base authentication methods.

Dec 94


Submit final draft of SOCKS protocol and authentication methods for RFC.


Request For Comments:







SOCKS Protocol Version 5



Username/Password Authentication for SOCKS V5



GSS-API Authentication Method for SOCKS Version 5

Current Meeting Report

Minutes of AFT WG at 45nd IETF-Oslo meeting

Authenticated Firewall Traversal Working Group Meeting
July 13, 1999
Osle, Norway

Chaired by Wei Lu <wlu@syl.dl.nec.com>
Reported by Wei Lu


Closing the revision of RFC 1928

Marc VanHeyningen summarized the revision of RFC 1928.
Highlights of the revision are:

- GSS-API returned to the MUST status as an authentication method for SOCKS.
- Added one UDP command option and one UDP subcommand.
- Added CHAP as a MAY authentication method. Most likely it will be removed from the final revision.

The WG agreed that after one more round of editing, the draft will move to the last call.

Closing the revision of RFC 1961

Marc VanHeyningen summarized the revision of RFC 1928.
Highlights of the revision are:

- Added SPNEGO to the GSS-API authentication.
- Removed "selective message protection level".

There is still a pending issue, the base authentication mechanism. LIPKEY and GSS-API-Easy have been mentioned as candidates for base mechanisms.

WG decided to look further into these 2 mechanisms, and agreed that the final choice will depend on CAT WG's progress on these 2 mechanisms. CAT's chair John Linn will look into this within CAT WG.

Announcing the merge of AFT and STP

Wei Lu announced the merge of STP into AFT. The STP related mailing list will be merged into AFT list.

Review the merged charter

AFT's new charter is inherited from STP's and has been sent to the AFT list. WG hasn't received any
objections yet. It will be submitted to IESG for final approval soon.

Wei Lu repeated the list of major working items discussed at the previous STP BOF.

Melinda Shore and most likely some others will propose additional requirements for firewall traversal of IP Telephony related applications.

Jamie Jason asked whether the new AFT charter will deal with policy related issues. Wei Lu commented that just like authentication related issues, it is better for AFT to leave them to other WG's. SOCKS protocol doesn't impose any restrictions on policy management implementation.

Outline the base protocol for the next version of SOCKS

Wei Lu briefly made some comments on the base protocol formats for the next version of SOCKS. Instead of one address field as in SOCKS Version 5, the new protocol will include two address fields in SOCKS request/reply messages.


None received.