📄 rfc2407.txt
字号:
Piper Standards Track [Page 6]
RFC 2407 IP Security Domain of Interpretation November 1998
4.4.1.2 PROTO_IPSEC_AH
The PROTO_IPSEC_AH type specifies IP packet authentication. The
default AH transform provides data origin authentication, integrity
protection, and replay detection. For export control considerations,
confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform.
4.4.1.3 PROTO_IPSEC_ESP
The PROTO_IPSEC_ESP type specifies IP packet confidentiality.
Authentication, if required, must be provided as part of the ESP
transform. The default ESP transform includes data origin
authentication, integrity protection, replay detection, and
confidentiality.
4.4.1.4 PROTO_IPCOMP
The PROTO_IPCOMP type specifies IP payload compression as defined in
[IPCOMP].
4.4.2 IPSEC ISAKMP Transform Identifiers
As part of an ISAKMP Phase I negotiation, the initiator's choice of
Key Exchange offerings is made using some host system policy
description. The actual selection of Key Exchange mechanism is made
using the standard ISAKMP Proposal Payload. The following table
lists the defined ISAKMP Phase I Transform Identifiers for the
Proposal Payload for the IPSEC DOI.
Transform Value
--------- -----
RESERVED 0
KEY_IKE 1
Within the ISAKMP and IPSEC DOI framework it is possible to define
key establishment protocols other than IKE (Oakley). Previous
versions of this document defined types both for manual keying and
for schemes based on use of a generic Key Distribution Center (KDC).
These identifiers have been removed from the current document.
The IPSEC DOI can still be extended later to include values for
additional non-Oakley key establishment protocols for ISAKMP and
IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
Protocol (GKMP) [RFC-2093].
Piper Standards Track [Page 7]
RFC 2407 IP Security Domain of Interpretation November 1998
4.4.2.1 KEY_IKE
The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
key exchange (IKE) as defined in the [IKE] document. All
implementations within the IPSEC DOI MUST support KEY_IKE.
4.4.3 IPSEC AH Transform Identifiers
The Authentication Header Protocol (AH) defines one mandatory and
several optional transforms used to provide authentication,
integrity, and replay detection. The following table lists the
defined AH Transform Identifiers for the ISAKMP Proposal Payload for
the IPSEC DOI.
Note: the Authentication Algorithm attribute MUST be specified to
identify the appropriate AH protection suite. For example, AH_MD5
can best be thought of as a generic AH transform using MD5. To
request the HMAC construction with AH, one specifies the AH_MD5
transform ID along with the Authentication Algorithm attribute set to
HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the
following sections.
Transform ID Value
------------ -----
RESERVED 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
Note: all mandatory-to-implement algorithms are listed as "MUST"
implement (e.g. AH_MD5) in the following sections. All other
algorithms are optional and MAY be implemented in any particular
implementation.
4.4.3.1 AH_MD5
The AH_MD5 type specifies a generic AH transform using MD5. The
actual protection suite is determined in concert with an associated
SA attribute list. A generic MD5 transform is currently undefined.
All implementations within the IPSEC DOI MUST support AH_MD5 along
with the Auth(HMAC-MD5) attribute. This suite is defined as the
HMAC-MD5-96 transform described in [HMACMD5].
The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH
transform (Key/Pad/Data/Key) described in RFC-1826.
Piper Standards Track [Page 8]
RFC 2407 IP Security Domain of Interpretation November 1998
Use of AH_MD5 with any other Authentication Algorithm attribute value
is currently undefined.
4.4.3.2 AH_SHA
The AH_SHA type specifies a generic AH transform using SHA-1. The
actual protection suite is determined in concert with an associated
SA attribute list. A generic SHA transform is currently undefined.
All implementations within the IPSEC DOI MUST support AH_SHA along
with the Auth(HMAC-SHA) attribute. This suite is defined as the
HMAC-SHA-1-96 transform described in [HMACSHA].
Use of AH_SHA with any other Authentication Algorithm attribute value
is currently undefined.
4.4.3.3 AH_DES
The AH_DES type specifies a generic AH transform using DES. The
actual protection suite is determined in concert with an associated
SA attribute list. A generic DES transform is currently undefined.
The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute
to be a DES-MAC transform. Implementations are not required to
support this mode.
Use of AH_DES with any other Authentication Algorithm attribute value
is currently undefined.
4.4.4 IPSEC ESP Transform Identifiers
The Encapsulating Security Payload (ESP) defines one mandatory and
many optional transforms used to provide data confidentiality. The
following table lists the defined ESP Transform Identifiers for the
ISAKMP Proposal Payload for the IPSEC DOI.
Note: when authentication, integrity protection, and replay detection
are required, the Authentication Algorithm attribute MUST be
specified to identify the appropriate ESP protection suite. For
example, to request HMAC-MD5 authentication with 3DES, one specifies
the ESP_3DES transform ID with the Authentication Algorithm attribute
set to HMAC-MD5. For additional processing requirements, see Section
4.5 (Authentication Algorithm).
Piper Standards Track [Page 9]
RFC 2407 IP Security Domain of Interpretation November 1998
Transform ID Value
------------ -----
RESERVED 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
Note: all mandatory-to-implement algorithms are listed as "MUST"
implement (e.g. ESP_DES) in the following sections. All other
algorithms are optional and MAY be implemented in any particular
implementation.
4.4.4.1 ESP_DES_IV64
The ESP_DES_IV64 type specifies the DES-CBC transform defined in
RFC-1827 and RFC-1829 using a 64-bit IV.
4.4.4.2 ESP_DES
The ESP_DES type specifies a generic DES transform using DES-CBC.
The actual protection suite is determined in concert with an
associated SA attribute list. A generic transform is currently
undefined.
All implementations within the IPSEC DOI MUST support ESP_DES along
with the Auth(HMAC-MD5) attribute. This suite is defined as the
[DES] transform, with authentication and integrity provided by HMAC
MD5 [HMACMD5].
4.4.4.3 ESP_3DES
The ESP_3DES type specifies a generic triple-DES transform. The
actual protection suite is determined in concert with an associated
SA attribute list. The generic transform is currently undefined.
All implementations within the IPSEC DOI are strongly encouraged to
support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite
is defined as the [ESPCBC] transform, with authentication and
integrity provided by HMAC MD5 [HMACMD5].
Piper Standards Track [Page 10]
RFC 2407 IP Security Domain of Interpretation November 1998
4.4.4.4 ESP_RC5
The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
4.4.4.5 ESP_IDEA
The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
4.4.4.6 ESP_CAST
The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
4.4.4.7 ESP_BLOWFISH
The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
[ESPCBC].
4.4.4.8 ESP_3IDEA
The ESP_3IDEA type is reserved for triple-IDEA.
4.4.4.9 ESP_DES_IV32
The ESP_DES_IV32 type specifies the DES-CBC transform defined in
RFC-1827 and RFC-1829 using a 32-bit IV.
4.4.4.10 ESP_RC4
The ESP_RC4 type is reserved for RC4.
4.4.4.11 ESP_NULL
The ESP_NULL type specifies no confidentiality is to be provided by
ESP. ESP_NULL is used when ESP is being used to tunnel packets which
require only authentication, integrity protection, and replay
detection.
All implementations within the IPSEC DOI MUST support ESP_NULL. The
ESP NULL transform is defined in [ESPNULL]. See the Authentication
Algorithm attribute description in Section 4.5 for additional
requirements relating to the use of ESP_NULL.
4.4.5 IPSEC IPCOMP Transform Identifiers
The IP Compression (IPCOMP) transforms define optional compression
algorithms that can be negotiated to provide for IP payload
compression ([IPCOMP]). The following table lists the defined IPCOMP
Transform Identifiers for the ISAKMP Proposal Payload within the
Piper Standards Track [Page 11]
RFC 2407 IP Security Domain of Interpretation November 1998
IPSEC DOI.
Transform ID Value
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1 IPCOMP_OUI
The IPCOMP_OUI type specifies a proprietary compression transform.
The IPCOMP_OUI type must be accompanied by an attribute which further
identifies the specific vendor algorithm.
4.4.5.2 IPCOMP_DEFLATE
The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
algorithm as specified in [DEFLATE].
4.4.5.3 IPCOMP_LZS
The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
algorithm as specified in [LZS].
4.5 IPSEC Security Association Attributes
The following SA attribute definitions are used in Phase II of an IKE
negotiation. Attribute types can be either Basic (B) or Variable-
Length (V). Encoding of these attributes is defined in the base
ISAKMP specification.
Attributes described as basic MUST NOT be encoded as variable.
Variable length attributes MAY be encoded as basic attributes if
their value can fit into two octets. See [IKE] for further
information on attribute encoding in the IPSEC DOI. All restrictions
listed in [IKE] also apply to the IPSEC DOI.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -