Internet Engineering Task Force
-
Technical committeeTypeAcronymIETF RFC 6775Published year2012Description
The IETF work in IPv6 over Low-power Wireless Personal Area Network
(6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other
similar link technologies have limited or no usage of multicast
signaling due to energy conservation. In addition, the wireless
network may not strictly follow the traditional concept of IP subnets
and IP links. IPv6 Neighbor Discovery was not designed for non-
transitive wireless links, as its reliance on the traditional IPv6
link concept and its heavy use of multicast make it inefficient and
sometimes impractical in a low-power and lossy network. This
document describes simple optimizations to IPv6 Neighbor Discovery,
its addressing mechanisms, and duplicate address detection for Low-
power Wireless Personal Area Networks and similar networks. The
document thus updates RFC 4944 to specify the use of the
optimizations defined here. -
Technical committeeTypeAcronymIETF RFC 6347Published year2012Description
This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.
The DTLS protocol provides communications privacy for datagram protocols.
The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.
Datagram semantics of the underlying transport are preserved by the DTLS protocol.
This document updates DTLS 1.0 to work with TLS version 1.2
-
Technical committeeTypeAcronymIETF RFC 5281Published year2008Description
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase.
During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase.
During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel.
The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2.
Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.
The data phase may also be used for additional, arbitrary data exchange.
-
Technical committeeTypeAcronymIETF RFC 5272Description
This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography
Standard), and2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
CMC also requires the use of the transport document and the requirements usage document along with this document for a full
definition. -
Technical committeeTypeAcronymIETF RFC 5247Description
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document
specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by
EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions
under which the key management guidelines described in RFC 4962 can be satisfied. -
Technical committeeTypeAcronymIETF RFC 5246Published year2008Description
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
-
Technical committeeTypeAcronymIETF RFC 4962Published year2007Description
This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The
guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and
difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. -
Technical committeeTypeAcronymIETF RFC 4422Published year2006Description
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.
-
Technical committeeTypeAcronymIETF RFC 4303Published year2005Description
This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide
confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). -
Technical committeeTypeAcronymIETF RFC 4210Published year2005Description
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP
provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system.