Previous | Table of Contents | Next |
The IETF Security Area (SEC) is comprised of eight working groups, as shown previously in Exhibit 2. Each working group has its own charter, goals, major accomplishments, and publications. As shown in Exhibit 3, each WG also maintains an Internet discussion list, where most of its work is done, as well as an on-line file archive. Additional up-to-date information about the WGs, including a list of area directors and WG chairs, can be found in the archive.
The Authenticated Firewall Traversal (AFT) Working Group is chartered to specify a protocol for application-layer support for firewall traversal. The working group intends to specify a traversal protocol supporting both TCP and user datagram protocol (UDP) applications with a general framework for authentication of the firewall traversal. To promote interoperability, the group also proposes a base authentication technique for use within the general authentication framework.
The output of the AFT WG consists of one or more Standards Track RFCs describing the traversal protocol, the base authentication methods, and a reference implementation of the protocol. The working groups initial work along these lines was the design and Internet-Draft specification of the SOCKS protocol and authentication methods in late 1994.
Working Group | General Discussion | Archive |
---|---|---|
Authenticated Firewall Traversal | aft@unify.com | ftp://ftp.unify.com/ietf/aft |
Common Authenticiation Technology | cat-ietf@mit.edu | ftp://bitsy.mit.edu/cat-ietf/archive/ |
Domain Name System Security | dns-security@tis.com | ftp://ftp.tis.com/pub/dns-security |
IP Security Protocol | ipsec@ans.net | ftp://ftp.ans.net/pub/archive/ipsec |
One Time Password Authentication | ietf-otp@bellcore.com | ftp://ftp.bellcore.com/pub/ietf-otp/archive |
Privacy-Enhanced Electronic Mail | pem-dev@tis.com | pem-dev-request@tis.com |
Public-Key Infrastructure (X.509) | ietf-pkix@tandem.com | ftp:/ftp.tandem.com/ieft/mailing-lists/current |
Web Transaction Security | www-security@nsmx.rutgers.edu | http://www-ns.rutgers.edu/www-security |
Note: To subscribe to these discussion lists (other than pkix), send an E-mail message to listname-request with the word subscribe in the message body. To subscribe to the pkix list, send a message to listserv@tandem.com and place subscribe your_E-mail ietf-pkix in the message body. |
The Common Authentication Technology (CAT) Working Group has a charter to define strong authentication mechanisms for a variety of protocol callers in such a way that the specifics of the underlying security mechanisms are transparent to those callers. By separating security implementation tasks from the tasks of integrating security data elements into caller protocols, those tasks can be partitioned and performed separately by implementers with different areas of expertise. This provides leverage for the IETF communitys security-oriented resources and allows protocol implementers to focus on the functions that their protocols are designed to provide, rather than on characteristics of security mechanisms. The CAT WG seeks to encourage uniformity and modularity in security approaches, supporting the use of common techniques and accommodating evolution of underlying technologies.
The CAT working group has pursued several interrelated tasks to achieve these goals. They are working toward agreements on a common service interface allowing callers to invoke security services and a common authentication token format, incorporating a means to identify the mechanism type in conjunction with the authentication data elements that should be interpreted. They are also examining suitable underlying mechanisms to implement these security functions. Two candidate architectures under consideration are Kerberos V5, based on secret-key technology and contributed by MIT, and ITU-T Rec. X.509-based public-key Distributed Authentication Services, being prepared for contribution by Digital.
The following RFCs have been published as a result of the work of the CAT WG:
The CAT WG has also written several Internet-Drafts on FTP security extensions; Kerberos V5, public-key, and other GSS-API mechanisms; and single-use authentication mechanisms with Kerberos.
The Domain Name System Security (DNSSEC) Working Group has a charter to specify data integrity and authentication enhancements to the domain name system (DNS) protocol to protect against unauthorized modification of data and masquerading of data origin. The specific mechanism to be added to the DNS protocol is a digital signature. The digital signature service will enable DNS resource records to be signed. Upon verification of the signatures, remote sites can have confidence in the accuracy of the records received.
The DNSSEC WG is exploring two primary issues with the aim of finding resolutions. The first issue is determining whether the resource records should be signed by the primary or secondary servers, or both, or by the start of authority (SOA) for the DNS zone; this issue is relevant because there are servers for sites that are not connected with Internet protocol (IP). The second issue is specifying the mechanism for the distribution of the public keys necessary to verify the digital signatures.
The DNSSEC WG is also operating under two working assumptions. First, backwards compatibility and co-existence with DNS servers and clients that do not support the proposed security services is required. Second, data in the DNS is considered public information, meaning that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group.
The DNSSEC working group has produced Internet-Drafts for DNS security extensions and a definition for mapping autonomous systems number into the DNS.
The Internet Protocol Security Protocol (IPSEC) Working Group has a charter to develop mechanisms to protect IP client protocols. A Network Layer security protocol will be developed that provides cryptographic security services supporting combinations of authentication, integrity, access control, and confidentiality. Newly defined IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) protocol formats will be independent of the cryptographic algorithm. Initial work is towards host-to-host security, followed by subnet-to-subnet and host-to-subnet security.
Previous | Table of Contents | Next |