key management

This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange.

This document presents an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) for the purpose of group key management. The protocol is in conformance with the Multicast Security (MSEC) Group Key Management architecture, which contains two components: member registration and group rekeying. Both components are required for a Group Controller/Key Server (GCKS) to provide authorized Group Members (GMs) with IPsec Group Security Associations (GSAs). The GMs then exchange IP multicast or other group traffic as IPsec packets.

This document obsoletes RFC 6407.

This document updates RFC 9048, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional extension providing ephemeral key exchange. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead.

This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256. The use of this mechanism provides protection against an attacker that manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier.

The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context.

This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified.

This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management.

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP").

The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the Quantum Internet and categorizes them. Some general requirements for the Quantum Internet are also discussed. The intent of this document is to describe a framework for applications and to describe a few selected application scenarios for the Quantum Internet. This document is a product of the Quantum Internet Research Group (QIRG).

The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA.

This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.

EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.

This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448.

RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation of Session-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods.

RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.

This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).

Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).

This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.

This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

This document also obsoletes RFC 2898.

This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).

This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.

This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.

The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.

These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.

The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.

This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.

The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.

The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).

The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).

Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.

This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]

The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.

Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]

This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]

This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]

This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]

This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.

This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.

This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. This memo provides information for the Internet community.

The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]

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. [STANDARDS-TRACK]

This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]

This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. This memo provides information for the Internet community.

This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]

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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. This memo provides information for the Internet community.

This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. [STANDARDS-TRACK]

This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.

The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. This memo provides information for the Internet community.

The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]

This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.

This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.

As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.

This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.

The purpose of this document is to make the AES Key Wrap algorithm

conveniently available to the Internet community. The United States

of America has adopted AES as the new encryption standard. The AES

Key Wrap algorithm will probably be adopted by the USA for

encryption of AES keys. The authors took most of the text in this

document from the draft AES Key Wrap posted by NIST.

The Hypertext Transfer Protocol (HTTP) Authentication Framework

includes two authentication schemes: Basic and Digest. Both schemes

employ a shared secret based mechanism for access authentication.

The Authentication and Key Agreement (AKA) mechanism performs user

authentication and session key distribution in Universal Mobile

Telecommunications System (UMTS) networks. AKA is a challenge-

response based mechanism that uses symmetric cryptography. This memo

specifies an AKA based one-time password generation mechanism for

HTTP Digest access authentication.

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.

This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community.

This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.

This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]

This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.

A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community.

This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]