|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some other
RFCs & Drafts
related to
Security
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
|
Last Update: May 13, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
|
|
| | |
RFC1321
04/1992
(21 p.)
[html]
[pdf(2)] |
R. Rivest |
|
The MD5 Message-Digest Algorithm |
|
This document describes the MD5 message-digest algorithm. The
algorithm takes as input a message of arbitrary length and produces
as output a 128-bit "fingerprint" or "message digest" of the input.
It is conjectured that it is computationally infeasible to produce
two messages having the same message digest, or to produce any
message having a given prespecified target message digest. The MD5
algorithm is intended for digital signature applications, where a
large file must be "compressed" in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem
such as RSA.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2025
10/1996
(45 p.)
[html]
[pdf(2)] |
C. Adams |
|
The Simple Public-Key GSS-API Mechanism (SPKM) |
|
This specification defines protocols, procedures, and conventions to
be employed by peers implementing the Generic Security Service
Application Program Interface (as specified in RFCs 1508 and 1509)
when using the Simple Public-Key Mechanism.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2315
03/1998
(32 p.)
[html]
[pdf(2)] |
B. Kaliski |
|
PKCS #7: Cryptographic Message Syntax - Version 1.5 |
|
This document describes a general syntax for data that may have
cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one
envelope can be nested inside another, or one party can sign some
previously enveloped digital data. It also allows arbitrary
attributes, such as signing time, to be authenticated along with the
content of a message, and provides for other attributes such as
countersignatures to be associated with a signature. A degenerate
case of the syntax provides a means for disseminating certificates
and certificate-revocation lists.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2692
09/1999
(14 p.)
[html]
[pdf(2)] |
C. Ellison |
|
SPKI Requirements |
The IETF Simple Public Key Infrastructure [SPKI] Working Group is
tasked with producing a certificate structure and operating procedure
to meet the needs of the Internet community for trust management in
as easy, simple and extensible a way as possible.
The SPKI Working Group first established a list of things one might
want to do with certificates (attached at the end of this document),
and then summarized that list of desires into requirements. This
document presents that summary of requirements.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2693
09/1999
(43 p.)
[html]
[pdf(2)] |
C. Ellison
B. Frantz
B. Lampson
R. Rivest
B. Thomas
T. Ylonen |
|
SPKI Certificate Theory |
The SPKI Working Group has developed a standard form for digital
certificates whose main purpose is authorization rather than
authentication. These structures bind either names or explicit
authorizations to keys or other objects. The binding to a key can be
directly to an explicit key, or indirectly through the hash of the
key or a name for it. The name and authorization structures can be
used separately or together. We use S-expressions as the standard
format for these certificates and define a canonical form for those
S-expressions. As part of this development, a mechanism for deriving
authorization decisions from a mixture of certificate types was
developed and is presented in this document.
This document gives the theory behind SPKI certificates and ACLs
without going into technical detail about those structures or their
uses.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2716
10/1999
(24 p.)
[html]
[pdf(2)] |
B. Aboba
D. Simon |
|
PPP EAP TLS Authentication Protocol |
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
also defines an extensible Link Control Protocol (LCP), which can be
used to negotiate authentication methods, as well as an Encryption
Control Protocol (ECP), used to negotiate data encryption over PPP
links, and a Compression Control Protocol (CCP), used to negotiate
compression methods. The Extensible Authentication Protocol (EAP) is
a PPP extension that provides support for additional authentication
methods within PPP.
Transport Level Security (TLS) provides for mutual authentication,
integrity-protected ciphersuite negotiation and key exchange between
two endpoints. This document describes how EAP-TLS, which includes
support for fragmentation and reassembly, provides for these TLS
mechanisms within EAP.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2743
01/2000
(101 p.)
[html]
[pdf(2)] |
J. Linn |
|
Generic Security Service Application Program Interface - Version 2, Update 1 |
The Generic Security Service Application Program Interface (GSS-API),
Version 2, as defined in [RFC-2078], provides security services to
callers in a generic fashion, supportable with a range of underlying
mechanisms and technologies and hence allowing source-level
portability of applications to different environments. This
specification defines GSS-API services and primitives at a level
independent of underlying mechanism and programming language
environment, and is to be complemented by other, related
specifications:
- documents defining specific parameter bindings for particular
language environments
- documents defining token formats, protocols, and procedures to be
implemented in order to realize GSS-API services atop particular
security mechanisms
This memo obsoletes [RFC-2078], making specific, incremental changes
in response to implementation experience and liaison requests. It is
intended, therefore, that this memo or a successor version thereto
will become the basis for subsequent progression of the GSS-API
specification on the standards track.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2744
01/2000
(101 p.)
[html]
[pdf(2)] |
J. Wray |
|
Generic Security Service API Version 2 : C-bindings |
This document specifies C language bindings for Version 2, Update 1
of the Generic Security Service Application Program Interface (GSS-
API), which is described at a language-independent conceptual level
in RFC 2743 [GSSAPI]. It obsoletes RFC-1509, making specific
incremental changes in response to implementation experience and
liaison requests. It is intended, therefore, that this memo or a
successor version thereof will become the basis for subsequent
progression of the GSS-API specification on the standards track.
The Generic Security Service Application Programming Interface
provides security services to its callers, and is intended for
implementation atop a variety of underlying cryptographic mechanisms.
Typically, GSS-API callers will be application protocols into which
security enhancements are integrated through invocation of services
provided by the GSS-API. The GSS-API allows a caller application to
authenticate a principal identity associated with a peer application,
to delegate rights to a peer, and to apply security services such as
confidentiality and integrity on a per-message basis.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2853
06/2000
(96 p.)
[html]
[pdf(2)] |
J. Kabat
M. Upadhyay |
|
Generic Security Service API Version 2 : Java Bindings |
The Generic Security Services Application Program Interface (GSS-API)
offers application programmers uniform access to security services
atop a variety of underlying cryptographic mechanisms. This document
specifies the Java bindings for GSS-API which is described at a
language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].
The GSS-API allows a caller application to authenticate a principal
identity, to delegate rights to a peer, and to apply security
services such as confidentiality and integrity on a per-message
basis. Examples of security mechanisms defined for GSS-API are The
Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5
GSS-API Mechanism [KERBV5].
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2898
09/2000
(34 p.)
[html]
[pdf(2)] |
B. Kaliski |
|
PKCS #5: Password-Based Cryptography Specification - Version 2.0 |
This memo represents a republication of PKCS #5 v2.0 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document, except for the security considerations section, is taken
directly from that specification.
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.
The recommendations are intended for general application within
computer and communications systems, and as such include a fair
amount of flexibility. They are particularly intended for the
protection of sensitive information such as private keys, as in PKCS
#8. It is expected that application standards and implementation
profiles based on these specifications may include additional
constraints.
Other cryptographic techniques based on passwords, such as password-based
key entity authentication and key establishment protocols
are outside the scope of this document. Guidelines for
the selection of passwords are also outside the scope.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2985
11/2000
(42 p.)
[html]
[pdf(2)] |
M. Nystrom
B. Kaliski |
|
PKCS #9: Selected Object Classes and Attribute Types - Version 2.0 |
This memo represents a republication of PKCS #9 v2.0 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document, except for the security considerations section, is taken
directly from that specification.
This memo provides a selection of object classes and attribute types
for use in conjunction with public-key cryptography and Lightweight
Directory Access Protocol (LDAP) accessible directories. It also
includes ASN.1 syntax for all constructs.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2986
11/2000
(14 p.)
[html]
[pdf(2)] |
M. Nystrom
B. Kaliski |
|
PKCS #10: Certification Request Syntax Specification - Version 1.7 |
This memo represents a republication of PKCS #10 v1.7 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document, except for the security considerations section, is taken
directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.
This memo describes a syntax for certification requests.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3174
09/2001
(22 p.)
[html]
[pdf(2)] |
D. Eastlake
P. Jones |
|
US Secure Hash Algorithm 1 (SHA1) |
|
The purpose of this document is to make the SHA-1 (Secure Hash
Algorithm 1) hash algorithm conveniently available to the Internet
community. The United States of America has adopted the SHA-1 hash
algorithm described herein as a Federal Information Processing
Standard. Most of the text herein was taken by the authors from FIPS
180-1. Only the C code implementation is "original".
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3610
09/2003
(22 p.)
[html]
[pdf(2)] |
D. Whiting
R. Housley
N. Ferguson |
|
Counter with CBC-MAC (CCM) |
|
Counter with CBC-MAC (CCM) is a generic authenticated encryption
block cipher mode. CCM is defined for use with 128-bit block
ciphers, such as the Advanced Encryption Standard (AES).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3631
12/2003
(20 p.)
[html]
[pdf(2)] |
S. Bellovin
J. Schiller
C. Kaufman |
|
Security Mechanisms for the Internet |
|
Security must be built into Internet Protocols for those protocols to
offer their services securely. Many security problems can be traced
to improper implementations. However, even a proper implementation
will have security problems if the fundamental protocol is itself
exploitable. Exactly how security should be implemented in a
protocol will vary, because of the structure of the protocol itself.
However, there are many protocols for which standard Internet
security mechanisms, already developed, may be applicable. The
precise one that is appropriate in any given situation can vary. We
review a number of different choices, explaining the properties of
each.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3760
04/2004
(22 p.)
[html]
[pdf(2)] |
D. Gustafson
M. Just
M. Nystrom |
|
Securely Available Credentials (SACRED)
- Credential Server Framework |
|
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.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4017
03/2005
(11 p.)
[html]
[pdf(2)] |
D. Stanley
J. Walker
B. Aboba |
|
Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs |
|
The IEEE 802.11i MAC Security Enhancements Amendment makes use of
IEEE 802.1X, which in turn relies on the Extensible Authentication
Protocol (EAP). This document defines requirements for EAP methods
used in IEEE 802.11 wireless LAN deployments. The material in this
document has been approved by IEEE 802.11 and is being presented as
an IETF RFC for informational purposes.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4049
04/2005
(7 p.)
[html]
[pdf(2)] |
R. Housley |
|
BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
|
This document specifies a new ASN.1 type for representing time:
BinaryTime. This document also specifies an alternate to the
signing-time attribute for use with the Cryptographic Message Syntax
(CMS) SignedData and AuthenticatedData content types; the binary-
signing-time attribute uses BinaryTime. CMS and the signing-time
attribute are defined in RFC 3852.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4108
08/2005
(61 p.)
[html]
[pdf(2)] |
R. Housley |
|
Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages |
|
This document describes the use of the Cryptographic Message Syntax
(CMS) to protect firmware packages, which provide object code for one
or more hardware module components. CMS is specified in RFC 3852. A
digital signature is used to protect the firmware package from
undetected modification and to provide data origin authentication.
Encryption is optionally used to protect the firmware package from
disclosure, and compression is optionally used to reduce the size of
the protected firmware package. A firmware package loading receipt
can optionally be generated to acknowledge the successful loading of
a firmware package. Similarly, a firmware package load error report
can optionally be generated to convey the failure to load a firmware
package.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4270
11/2005
(12 p.)
[html]
[pdf(2)] |
P. Hoffman
B. Schneier |
|
Attacks on Cryptographic Hashes in Internet Protocols |
|
Recent announcements of better-than-expected collision attacks in
popular hash algorithms have caused some people to question whether
common Internet protocols need to be changed, and if so, how. This
document summarizes the use of hashes in many protocols, discusses
how the collision attacks affect and do not affect the protocols,
shows how to thwart known attacks on digital certificates, and
discusses future directions for protocol designers.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4634
07/2006
(108 p.)
[html]
[pdf(2)] |
D. Eastlake
T. Hansen |
|
US Secure Hash Algorithms (SHA and HMAC-SHA) |
The United States of America has adopted a suite of Secure Hash
Algorithms (SHAs), including four beyond SHA-1, as part of a Federal
Information Processing Standard (FIPS), specifically SHA-224 (RFC
3874), SHA-256, SHA-384, and SHA-512. The purpose of this document
is to make source code performing these hash functions conveniently
available to the Internet community. The sample code supports input
strings of arbitrary bit length. SHA-1's sample code from RFC 3174
has also been updated to handle input strings of arbitrary bit
length. Most of the text herein was adapted by the authors from FIPS
180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is
also included.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4758
11/2006
(54 p.)
[html]
[pdf(2)] |
M. Nystroem |
|
Cryptographic Token Key Initialization Protocol (CT-KIP)
Version 1.0 Revision 1 |
This document constitutes Revision 1 of Cryptographic Token Key
Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories'
One-Time Password Specifications (OTPS) series. The body of this
document, except for the intellectual property considerations
section, is taken from the CT-KIP Version 1.0 document, but comments
received during the IETF review are reflected; hence, the status of a
revised version. As no "bits-on-the-wire" have changed, the protocol
specified herein is compatible with CT-KIP Version 1.0.
CT-KIP is a client-server protocol for initialization (and
configuration) of cryptographic tokens. The protocol requires
neither private-key capabilities in the cryptographic tokens, nor an
established public-key infrastructure. Provisioned (or generated)
secrets will only be available to the server and the cryptographic
token itself.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4772
12/2006
(28 p.)
[html]
[pdf(2)] |
S. Kelly |
|
Security Implications of Using the Data Encryption Standard (DES) |
|
The Data Encryption Standard (DES) is susceptible to brute-force
attacks, which are well within the reach of a modestly financed
adversary. As a result, DES has been deprecated, and replaced by the
Advanced Encryption Standard (AES). Nonetheless, many applications
continue to rely on DES for security, and designers and implementers
continue to support it in new applications. While this is not always
inappropriate, it frequently is. This note discusses DES security
implications in detail, so that designers and implementers have all
the information they need to make judicious decisions regarding its
use.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4809
02/2007
(45 p.)
[html]
[pdf(2)] |
C. Bonatti
S. Turner
G. Lebovitz |
|
Requirements for an IPsec Certificate Management Profile |
|
This informational document describes and identifies the requirements
for transactions to handle Public Key Certificate (PKC) lifecycle
transactions between Internet Protocol Security (IPsec) Virtual
Private Network (VPN) Systems using Internet Key Exchange (IKE)
(versions 1 and 2) and Public Key Infrastructure (PKI) Systems.
These requirements are designed to meet the needs of enterprise-scale
IPsec VPN deployments. It is intended that a standards track profile
of a management protocol will be created to address many of these
requirements.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4945
08/2007
(43 p.)
[html]
[pdf(2)] |
B. Korver |
|
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX |
|
The Internet Key Exchange (IKE) and Public Key Infrastructure for
X.509 (PKIX) certificate profile both provide frameworks that must be
profiled for use in a given application. This document provides a
profile of IKE and PKIX that defines the requirements for using PKI
technology in the context of IKE/IPsec. The document complements
protocol specifications such as IKEv1 and IKEv2, which assume the
existence of public key certificates and related keying materials,
but which do not address PKI issues explicitly. This document
addresses those issues. The intended audience is implementers of PKI
for IPsec.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4949
08/2007
(365 p.)
[html]
[pdf(2)] |
R. Shirey |
|
Internet Security Glossary, Version 2 |
|
This Glossary provides definitions, abbreviations, and explanations
of terminology for information system security. The 334 pages of
entries offer recommendations to improve the comprehensibility of
written material that is generated in the Internet Standards Process
(RFC 2026). The recommendations follow the principles that such
writing should (a) use the same term or definition whenever the same
concept is mentioned; (b) use terms in their plainest, dictionary
sense; (c) use terms that are already well-established in open
publications; and (d) avoid terms that either favor a particular
vendor or favor a particular technology or mechanism over other,
competing techniques that already exist or could be developed.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5114
01/2008
(23 p.)
[html]
[pdf(2)] |
M. Lepinski
S. Kent |
|
Additional Diffie-Hellman Groups for Use with IETF Standards |
This document describes eight Diffie-Hellman groups that can be used
in conjunction with IETF protocols to provide security for Internet
communications. The groups allow implementers to use the same groups
with a variety of security protocols, e.g., SMIME, Secure SHell
(SSH), Transport Layer Security (TLS), and Internet Key Exchange
(IKE).
All of these groups comply in form and structure with relevant
standards from ISO, ANSI, NIST, and the IEEE. These groups are
compatible with all IETF standards that make use of Diffie-Hellman or
Elliptic Curve Diffie-Hellman cryptography.
These groups and the associated test data are defined by NIST on
their web site [EX80056A], but have not yet (as of this writing) been
published in a formal NIST document. Publication of these groups and
associated test data, as well as describing how to use Diffie-Hellman
and Elliptic Curve Diffie-Hellman for key agreement in all of the
protocols cited below, in one RFC, will facilitate development of
interoperable implementations and support the Federal Information
Processing Standard (FIPS) validation of implementations that make
use of these groups.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5116
01/2008
(22 p.)
[html]
[pdf(2)] |
D. McGrew |
|
An Interface and Algorithms for Authenticated Encryption |
|
This document defines algorithms for Authenticated Encryption with
Associated Data (AEAD), and defines a uniform interface and a
registry for such algorithms. The interface and registry can be used
as an application-independent set of cryptoalgorithm suites. This
approach provides advantages in efficiency and security, and promotes
the reuse of crypto implementations.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
|
|
| | |
dharkins-siv-aes-02
In Last Call
Feb 25, 2008
(25 p.)
[pdf(2)]
[html]
|
D. Harkins |
|
SIV Authenticated Encryption using AES |
|
This memo describes SIV, a block cipher mode of operation. SIV takes
a key, a plaintext, and multiple variable-length octet strings which
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## Miscellaneous
|
|
|
|
|
|
|
|
|
|
| | |
brunner-ikev2-
mediation-00
ID Exists
Apr 16, 2008
(36 p.)
[pdf(2)]
[html]
|
T. Brunner |
|
IKEv2 Mediation Extension |
|
This document describes the IKEv2 Mediation Extension (IKE-ME), a
connectivity extension to the Internet Key Exchange IKEv2. IKE-ME
allows two peers, each behind one or more Network Address Translators
(NATs) or firewalls to establish a direct and secure connection
without the need to configure any of the intermediate network
devices. To establish this direct connection, a process similar to
Interactive Connectivity Establishment (ICE) is used.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
|
|
