14.1 Active IETF Working Groups in Security Area
The goal of the OpenPGP working group is to provide IETF standards
for the algorithms and formats of PGP
processed objects as well as providing the MIME framework for exchanging
them via e-mail or other transport protocols.
The S/MIME Working Group has completed five Proposed Standards that comprise the S/MIME version 3 specification. Current efforts build on these base specifications.
The use of Diffie-Hellman Key Agreement as the mandatory to implement key establishment mechanism may expose some implementations to vulnerabilities based on "small subgroup" attacks. An informational document will be prepared describing techniques that can be used to avoid these attacks.
The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. An additional suite of 'mandatory to implement' algorithms may be selected.
To aid implementers, documents containing example output for CMS will be collected and published. Some of the examples will include structures and signed attributed defined in the Enhanced Security Services (ESS) document.
Current methods of publishing certificates in the Directory do not allow the inclusion of secondary support information such as the SMimeCapabilities attribute. A method of publishing certificates along with authenticated secondary support information will be defined.
In some situations it would be advantageous for the CMS RecipientInfo structure to support additional key management techniques, including cryptographic keys derived from passwords. A mechanism to facilitate the definition of additional key management techniques will be defined. S/MIME version 3 permits the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to multiple message recipients will be developed. Mail List Agents (MLAs) are one user of symmetric key-encryption keys. The specification will be cryptographic algorithm independent.
S/MIME version 3 supports security labels. Specifications that show how this feature can be used to implement an organizational security policy will be developed. Security policies from large organizations will be used as examples.
S/MIME version 3 can be used to protect electronic mail to and from a domain. In such an environment, S/MIME v3 processing is performed by message transfer agents, guards, and gateways in order to provide "Domain Security Services." Mechanisms are needed to solve a number of interoperability problems and technical limitations that arise when domains supporting different security policies wish to interoperate.
The S/MIME Working Group will attempt to coordinate its efforts with
the OpenPGP Working Group in areas where the work of the two groups overlap.
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.
The goal of the Common Authentication Technology (CAT) Working Group is to provide distributed security services (which have included authentication, integrity, and confidentiality, and may broaden to include authorization) to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms.
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 implementors with different areas of xpertise. This provides leverage for the IETF community's security-oriented resources, and allows protocol implementors to focus on the functions their protocols are designed to provide rather than on characteristics of security mechanisms. CAT seeks to encourage uniformity and modularity in security approaches, supporting the use of common techniques and accommodating evolution of underlying technologies.
In support of these goals, the working group pursues several interrelated
tasks. We have defined a common service interface (GSS-API)
allowing callers to invoke security services in association-oriented environments,
with an associated token format identifying the security mechanism being
employed. Existing documents provide C language bindings for GSS-API; currently
ongoing work is defining bindings for Java. Authorization interfaces are
currently being evaluated as a related area for follow-on work, with the
level of achievable portability an important consideration. The CAT Working
Group also defines supporting mechanisms to provide security services;
current activity includes specification of "low-infrastructure" mechanisms
to support ease of deployment and use.
The Domain Name System Security Working Group (DNSSEC) will ensure enhancements to the secure DNS protocol to protect the dynamic update operation of the DNS. Specifically, it must be possible to detect the replay of update transactions and it must be possible to order update transactions. Clock synchronization should be addressed as well as all of the dynamic update specification.
Some of the issues to be explored and resolved include
One essential assumption has been identified: data in the DNS is
considered public information. This assumption means that discussions and
proposals involving data confidentiality and access control are explicitly
outside the scope of this working group.
Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality.
The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security. The Internet
Key Management Protocol (IKMP) will be specified as an application layer
protocol that is independent of the lower layer security protocol.
Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress.
The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups.
The outputs of this working group will be:
One form of attack on computing systems connected to the Internet is eavesdropping on network connections to obtain login id's and passwords of legitimate users [RFC 1704]. Bellcore's S/KEY(TM) one-time password system was designed to counter this type of attack, called a replay attack [RFC 1760]. Several one-time password implementations compatible with Bellcore's S/KEY (TM) system exist. These implementations are increasingly widely deployed in the Internet to protect against passive attacks.
The object of this working group is to write a standards track RFC for one-time password technology, using the technology in the Bellcore S/KEY system and related interoperable packages (e.g., logdaemon, NRL OPIE) as the basis for the group's effort. The standards-track RFC will enhance multi-vendor interoperability in one-time password authentication technologies and thereby help reduce security risks in the Internet.
General authentication servers are outside the scope of this working group. The ``S/Key-0'' system being considered for use in Kerberos is outside the scope of this working group.
The standards-track specification will describe how this one-time password technology can be used with at least the MD4, MD5, and SHA algorithms. The standard one-time password dictionary from RFC 1760 will be reused in order to maintain backwards compatibility with the various deployed systems, however, support for hexadecimal format passwords will also be mandatory to implement. The standard might specify passphrase quality checks for the secret passphrase. The standard will be specified so as to eliminate any possible conflict with the Bellcore trademark on the term ''S/Key.''
An Informational RFC might also be issued that describes conventions
for the UNIX commands relating to one-time passwords, including command(s)
to securely update a remote one-time password.
The PKIX Working Group was established in the Fall of 1995 with the intent of developing Internet standards needed to support an X.509-based PKI. Several informational and standards track documents in support of the original goals of the WG have been approved by the IESG. The first of these standards, RFC 2459, profiles the X.509 version 3 certificates and version 2 CRLs for use in the Internet. The Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), and the Certificate Management Request Format (CRMF) (RFC 2511) have been approved, as have profiles for the use of LDAP v2 for certificate and CRL storage (RFC 2587) and the use of FTP and HTTP for transport of PKI operations (RFC 2585). RFC 2527, an informational RFC on guidelines for certificate policies and practices also has been published, and the IESG has approved publication of an information RFC on use of KEA (RFC 2528) and is expected to do the same for ECDSA. Work continues on a second certificate management protocol, CMC, closely aligned with the PKCS publications and with the cryptographic message syntax (CMS) developed for S/MIME. A roadmap, providing a guide to the growing set of PKIX document, is also being developed as an informational RFC.
The working group is now embarking on additional standards work to develop protocols that are either integral to PKI management, or that are otherwise closely related to PKI use. Work is ongoing on alternative certificate revocation methods. There also is work defining conventions for certificate name forms and extension usage for "qualified certificates," certificates designed for use in (legally binding) non-repudiation contexts. Finally, work is underway on protocols for time stamping and data certification. These protocols are designed primarily to support non-repudiation, making use of certificates and CRLs, and are so tightly bound to PKI use that they warrant coverage under this working group.
Additional work will be initiated on a profile for X.509 attribute certificates,
resulting in a new RFC and, perhaps, in extensions to existing certificate
management standards to accommodate differences between attribute certificates
and public-key certificates.
Many Internet protocols and applications which use the Internet employ public key technology for security purposes and require a public key infrastructure to manage public keys.
The task of the working group will be to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use. For purposes of the working group, the resulting formats and protocols are to be known as the Simple Public Key Infrastructure, or SPKI.
The SPKI is intended to provide mechanisms to support security in a
wide range of internet applications, including IPSEC protocols, encrypted
electronic mail and WWW documents, payment protocols, and any other application
which will require the use of public key certificates and the ability to
access them. It is intended that the Simple Public Key Infrastructure will
support a range of trust models.
For trust models to be truly portable across the Internet, transactions must be anchored so they are comparable. The one shared commodity that can be widely agreed upon is time, and the ability to authenticate the source of the time can assist in providing such portability in trust. The ability to securely obtain time from authenticated sources is thus becoming a key factor in security and non-repudiation.
Current IETF protocols address the distribution of time, and there is also a project for the generation of cryptographically protected timestamps. Existing approaches to distributing time are vulnerable to external attack and tampering, as these do not take advantage of advances in public key infrastructure and cryptographic methods, and require distribution of cryptographic keys via nonscalable out-of-band means. Securing time distribution using PKI mechanisms allows the process to scale and minimizes risk.
The purpose of this working group is to define the message formats and protocols - specifically, modifications to the existing Network Time Protocol (NTP) - which are necessary to support the authenticated distribution of time for the Internet. The working group will be chartered for a period of 12 months to meet this goal. Utilization of previous research in this area is expected.
Work will concentrate on the Internet-based NTP, to be enhanced with
the addition of public-key based authentication and security. The working
group expects to enhance NTP by way of occasional "setup" interchanges
between client and time server to establish a shared secret, followed by
normal NTP interchanges secured via the shared secret. The output of the
working group is expected to be a standards-track document.
The goal of the working group is to update and standardize the popular SSH protocol. SSH provides support for secure remote login, secure file transfer, and secure TCP/IP and X11 forwardings. It can automatically encrypt, authenticate, and compress transmitted data. The working group will attempt to assure that the SSH protocol
The resulting protocol will operate over TCP/IP or other reliable
but insecure transport. It is intended to be implemented at the application
level.
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.
The goal of the Web Transaction Security Working Group is to develop
requirements and a specification for the provision of security services
to Web transaction, e.g., transactions using HyperText Transport Protocol
(HTTP). This work will proceed in parallel to and independently of the
development of non-security features in the HTTP Working Group. The working
group will prepare two documents for submission as Internet Drafts; an
HTTP Security Requirements Specification, and an HTTP Security Protocol
Specification. The latter will be submitted as a Standards Track RFC.
Digital signatures provide integrity, signature assurance and non-repudiatability over Web data. Such features are especially important for documents that represent commitments such as contracts, price lists, and manifests. In view of recent Web technology developments, the proposed work will address the digital signing of documents (any Web resource addressable by a URI) using XML syntax. This capability is critical for a variety of electronic commerce applications, including payment tools.
.