RFC relevance of algorithm

As per Relevance of the word algorithm, we have this rfc below:

Network Working Group R.
Request for Comments: 2411 Sable Technology
Category: Informational N.
Bay
R.

November 1998

IP
Document

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

The IPsec protocol suite is used to provide privacy
authentication services at the IP layer. Several documents are
to describe this protocol suite. The interrelationship
organization of the various documents covering the IPsec protocol
discussed here. An explanation of what to find in which document
and what to include in new Encryption Algorithm and
Algorithm documents are described

Table of

1. Introduction ................................................2
2. Interrelationship of IPsec Documents ........................2
3. Keying Material .............................................4
4. Recommended Content of Algorithm Documents ..................5
4.1 Encryption and Authentication Algorithms ...................5
4.2 Encryption Algorithms ......................................6
4.3 Authentication Algorithms ..................................7
5. Security Considerations .....................................8
6. Acknowledgments .............................................8
7. References ..................................................9
8. Authors' Addresses .........................................10
9. Full Copyright Statement ...................................11

Thayer, et. al. Informational [Page 1]

RFC 2411 IP Security Document Roadmap November 1998

1.

This document is intended to provide guidelines for the
of collateral specifications describing the use of new encryption
authentication algorithms with the ESP protocol, described in [ESP
and new authentication algorithms used with the AH protocol
described in [AH]. ESP and AH are part of the IP
architecture described in [Arch]. There is a requirement for
well-known procedure that can be used to add new
algorithms or authentication algorithms to ESP and AH, not only
the initial document set is undergoing development but after the
documents have achieved RFC status. Following the
discussed below simplifies adding new algorithms and reduces
amount of redundant documentation

The goal in writing a new Encryption Algorithm or
Algorithm document is to concentrate on the application of
specific algorithm within ESP and AH. General ESP and AH concepts
definitions, and issues are covered in the ESP and AH documents.
algorithms themselves are not described in these documents.
gives us the capability to add new algorithms and also specify
any given algorithm might interact with other algorithms. The
is to achieve the goal of avoiding duplication of information
excessive numbers of documents, the so-called "draft explosion
effect

2. Interrelationship of IPsec

The documents describing the set of IPsec protocols are divided
seven groups. This is illustrated in Figure 1. There is a
Architecture document which broadly covers the general concepts
security requirements, definitions, and mechanisms defining
technology

There is an ESP Protocol document and an AH Protocol document
covers the packet format and general issues regarding the
protocols. These protocol documents also contain default values
appropriate, such as the default padding contents, and mandatory
implement algorithms. These documents dictate some of the values
the Domain Of Interpretation document [DOI]. Note the DOI
is itself part of the IANA Assigned Numbers mechanism and so
values described in the DOI are well-known. See [DOI] for
information on the mechanism

The "Encryption Algorithm" document set, shown on the left, is
set of documents describing how various encryption algorithms
used for ESP. These documents are intended to fit in this roadmap
and should avoid overlap with the ESP protocol document and with

Thayer, et. al. Informational [Page 2]

RFC 2411 IP Security Document Roadmap November 1998

Authentication Algorithm documents. Examples of this document
the [DES-Detroit] and [CBC] documents. When these or
encryption algorithms are used for ESP, the DOI document has
indicate certain values, such as an encryption algorithm identifier
so these documents provide input to the DOI

The "Authentication Algorithm" document set, shown on the right,
the set of documents describing how various authentication
are used for both ESP and AH. These documents are intended to fit
this roadmap, and should avoid overlap with the AH protocol
and with the Encryption Algorithm documents. Examples of
document are the [HMAC-MD5], and [HMAC-SHA-1] documents. When
or other algorithms are used for either ESP or AH, the DOI
has to indicate certain values, such as algorithm type, so
documents provide input to the DOI

The "Key Management Documents", shown at the bottom, are
documents describing the IETF standards-track key management schemes
These documents provide certain values for the DOI also. Note
issues of key management should be indicated here and not in,
example, the ESP and AH protocol documents. Currently this
represents [ISAKMP], [Oakley], and [Resolution].

The DOI document, shown in the middle, contains values needed for
other documents to relate to each other. This includes for
encryption algorithms, authentication algorithms, and
parameters such as key lifetimes

Thayer, et. al. Informational [Page 3]

RFC 2411 IP Security Document Roadmap November 1998

+--------------+
| Architecture |
+--------------+
v
+<-<-<-<-+ +->->->->+
v
+----------+ +----------+
| ESP | | AH |
| Protocol | | Protocol |
+----------+ +----------+
v v v
v +->->->->->->->->+ v
v v v v
v v v v
v +------------+ +----------------+
v | +------------+ | +----------------+
v | | Encryption | | | Authentication |
v +-| Algorithm | +-| Algorithm |
v +------------+ +----------------+
v v v
v v +-----+ v
+>->->->-+->->->->| DOI |<-<-<-<-+-<-<-<-<-+
+-----+
^
^
+------------+
| KEY |
| MANAGEMENT |
+------------+

Figure 1. IPsec Document Roadmap

3. Keying

Describing the encryption and authentication algorithms in
documents raises the issue of how the key management protocols
the required keying material length for the desired algorithms
used together with ESP. It also raises the issue of how to
the keying material. This is known as the "slicing and dicing
information

Each Encryption Algorithm and Authentication Algorithm
should specify their respective key attributes (e.g. how to pad
location of parity bits, key order for multi-keyed algorithms,
length). The key management protocols should use the length of
keys specified in the respective Algorithm documents to generate
keying material of required length

Thayer, et. al. Informational [Page 4]

RFC 2411 IP Security Document Roadmap November 1998

The key management protocol generates keying material with
strength and size to generate keys for individual algorithms.
IPsec Architecture document specifies how keys are extracted from
single block of keying material when multiple keys are required (e.g
ESP with authentication). The Encryption Algorithm

Authentication Algorithm documents are responsible for specifying
key sizes and strengths for each algorithm. However, whether
entire keying material is passed down to the kernel to
slicing and dicing or if the keys are sliced and diced by
management protocol is an implementation issue. The AH
document has no such requirement

4. Recommended Content of Algorithm

The document describing how a specific encryption or
algorithm is used should contain information appropriate to
encryption or authentication algorithm. This section enumerates
information should be provided. It is the intention of the
roadmap that

. General protocol information goes in the respective ESP or
protocol documents
. Key management information goes in the key management documents
. Assigned values and constants of negotiable items go in the
document

Encryption and authentication algorithms require some set of
parameters or have optional modes of operation (e.g. IVs
authentication data lengths, and key lengths). To help
some complexity involved with key management having to
large numbers of algorithm-specific parameters, encryption
authentication algorithm documents will select fixed values for
parameters when it is deemed technically reasonable and feasible

Note, the following information is intended as a general
only

4.1 Encryption and Authentication

This section describes the information that should be included
both Encryption Algorithm and Authentication Algorithm documents

Keying

. Size of keys, including minimum, maximum, recommended and/
required sizes. Note: the security considerations section
address any weakness in specific sizes

Thayer, et. al. Informational [Page 5]

RFC 2411 IP Security Document Roadmap November 1998

. Recommended or required pseudo-random number generator
and attributes to provide sufficiently strong keys. [RANDOM
provides recommendations on generating strong randomness for
with security
. Format of keying material
. Known weak keys or references to documentation on known weak keys
. Recommended or required processing of input keying material
as parity generation or checking
. Requirements and/or recommendations on how often the
material should be refreshed

Performance
. Any available estimates on performance of this algorithm
. Any available comparison data (e.g., compared against DES
MD5).
. Input size or other considerations that could improve or
performance

ESP Environmental
. Any known issues regarding interactions between this algorithm
other aspects of ESP, such as use of certain
schemes. Note: As new encryption and authentication
are applied to ESP, the later documents will be required
address interactions with previously specified algorithms

Payload Content and Format
. Specification of size, placement, and content of algorithm
specific fields not defined in the ESP or AH protocol
(e.g., IV).

Security
. Discuss any known attacks
. Discuss any known common implementation pitfalls, such as use
weak random number generators
. Discuss any relevant validation procedures, such as test vectors
[RFC-2202] is an example document containing test vectors
a set of authentication algorithms

4.2 Encryption

This section describes the information that should be included in
Encryption Algorithm documents

Encryption Algorithm
. General information how this encryption algorithm is to be used
ESP
. Description of background material and formal
description

Thayer, et. al. Informational [Page 6]

RFC 2411 IP Security Document Roadmap November 1998

. Features of this encryption algorithm to be used by ESP,
encryption and/or authentication
. Mention of any availability issues such as Intellectual
considerations
. References, in IETF style, to background material such as
documents

Algorithm Modes of
. Description of how the algorithm is operated, whether it is
mode or streaming mode or other
. Requirements for input or output block format
. Padding requirements of this algorithm. Note: there is a
for padding, specified in the base ESP document, so this is
needed if the default cannot be used
. Any algorithm-specific operating parameters, such as number
rounds
. Identify optional parameters and optional methods of operation
pick reasonable fixed values and methods with explicit
explanations
. Identify those optional parameters in which values and
should remain optional with explicit technical explanations on
fixed values and methods should not be used
. Defaults and mandatory ranges on algorithm-specific
parameters that could not be fixed

4.3 Authentication

This section describes the information that should be included in
Authentication Algorithm documents. In most cases, an
algorithm will operate the same whether it is used for ESP or AH
This should be represented in a single Authentication
document

Authentication Algorithm
. General information on how this authentication algorithm is to
used with ESP and AH
. Description of background material and formal
description
. Features of this authentication algorithm
. Mention of any availability issues such as Intellectual
considerations
. References, in IETF style, to background material such
FIPS documents and definitive descriptions of
algorithms

Algorithm Modes of
. Description of how the algorithm is operated

Thayer, et. al. Informational [Page 7]

RFC 2411 IP Security Document Roadmap November 1998

. Algorithm-specific operating parameters, such as number
rounds, and input or output block format
. Implicit and explicit padding requirements of this algorithm
Note: There is a default method for padding of
authentication data field specified in the AH protocol document
This is only needed if the default cannot be used
. Identify optional parameters and optional methods of operation
pick reasonable fixed values and methods with explicit
explanations
. Identify those optional parameters in which values and
should remain optional with explicit technical explanations on
fixed values and methods should not be used
. Defaults and mandatory ranges on algorithm-specific
parameters that could not be fixed
. Authentication data comparison criteria for this algorithm. Note
There is a default method for verifying the authentication
specified in the AH protocol document. This is only needed if
default cannot be used (e.g. when using a signed hash).

5. Security

This document provides a roadmap and guidelines for
Encryption and Authentication Algorithm documents. The reader
follow all the security procedures and guidelines described in
IPsec Architecture, ESP Protocol, AH Protocol, Encryption Algorithm
and Authentication Algorithm documents. Note that many
algorithms are not considered secure if they are not used with
sort of authentication mechanism

6.

Several Internet drafts were referenced in writing this document
Depending on where the documents are on (or off) the IETF
track these may not be available through the IETF RFC repositories
In certain cases the reader may want to know what version of
documents were referenced. These documents are

. DES-Detroit: this is the ANX Workshop style of ESP, based on
Hughes draft as modified by Cheryl Madson and published on the
mailing list
. DOI: draft-ietf-ipsec-ipsec-doi-02.txt
. 3DES: this is document>.
. CAST: this is draft-ietf-ipsec-esp-cast-128-cbc-00.txt, as
to relate to this document
. ESP: draft-ietf-ipsec-esp-04.txt, mailed to the IETF mailing
in May/June 1997.
. AH: draft-ietf-ipsec-auth-05.txt, mailed to the IETF mailing
in May/June 1997.

Thayer, et. al. Informational [Page 8]

RFC 2411 IP Security Document Roadmap November 1998

. HUGHES: this is draft-ietf-ipsec-esp-des-md5-03.
. ISAKMP: There are three documents describing ISAKMP. These
draft-ietf-ipsec-isakmp-07.txt, draft-ietf-ipsec-isakmp-oakley
03.txt, and draft-ietf-ipsec-ipsec-doi-02.txt

7.

[CBC] Periera, R., and R. Adams, "The ESP CBC-Mode
Algorithms", RFC 2451, November 1998.

[Arch] Kent, S., and R. Atkinson, "Security Architecture
the Internet Protocol", RFC 2401, November 1998.

[DES-Detroit] Madson, C., and N. Doraswamy, "The ESP DES-CBC
Algorithm With Explicit IV", RFC 2405, November 1998.

[DOI] Piper, D., "The Internet IP Security Domain
Interpretation for ISAKMP", RFC 2407, November 1998.

[AH] Kent, S., and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.

[ESP] Kent, S., and R. Atkinson, "IP Encapsulating
Payload (ESP)", RFC 2406, November 1998.

[HMAC] Krawczyk, K., Bellare, M., and R. Canetti, "HMAC
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.

[HMAC-MD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5
ESP and AH", RFC 2403, November 1998.

[HMAC-SHA-1] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1
ESP and AH", RFC 2404, November 1998.

[RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "
Recommendations for Security", RFC 1750, December 1994.

[RFC-2202] Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5
HMAC-SHA-1", RFC 2202, March 1997.

Thayer, et. al. Informational [Page 9]

RFC 2411 IP Security Document Roadmap November 1998

8. Authors'

Rodney
Sable Technology
246 Walnut
Newton, Massachusetts 02160

EMail: mailto:rodney@sabletech.

Naganand
Bay

EMail: naganand@baynetworks.

Rob

EMail: rob.glenn@nist.

Thayer, et. al. Informational [Page 10]

RFC 2411 IP Security Document Roadmap November 1998

9. Full Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Thayer, et. al. Informational [Page 11]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX