📄 rfc2407.txt
字号:
o Integrity Category Bitmap (variable length) - A bitmap used to
designate integrity categories (compartments) that are required.
The bitmap MUST be padded with zero (0) to align on the next
32-bit boundary.
4.6.1.1 IPSEC Labeled Domain Identifiers
The following table lists the assigned values for the Labeled Domain
Identifier field contained in the Situation field of the Security
Association Payload.
Piper Standards Track [Page 18]
RFC 2407 IP Security Domain of Interpretation November 1998
Domain Value
------- -----
RESERVED 0
4.6.2 Identification Payload Content
The Identification Payload is used to identify the initiator of the
Security Association. The identity of the initiator SHOULD be used
by the responder to determine the correct host system security policy
requirement for the association. For example, a host might choose to
require authentication and integrity without confidentiality (AH)
from a certain set of IP addresses and full authentication with
confidentiality (ESP) from another range of IP addresses. The
Identification Payload provides information that can be used by the
responder to make this decision.
During Phase I negotiations, the ID port and protocol fields MUST be
set to zero or to UDP port 500. If an implementation receives any
other values, this MUST be treated as an error and the security
association setup MUST be aborted. This event SHOULD be auditable.
The following diagram illustrates the content of the Identification
Payload.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identification Payload Format
The Identification Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of
the next payload in the message. If the current payload is the
last in the message, this field will be zero (0).
o RESERVED (1 octet) - Unused, must be zero (0).
o Payload Length (2 octets) - Length, in octets, of the
identification data, including the generic header.
o Identification Type (1 octet) - Value describing the identity
information found in the Identification Data field.
Piper Standards Track [Page 19]
RFC 2407 IP Security Domain of Interpretation November 1998
o Protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g. UDP/TCP). A value of zero means that the
Protocol ID field should be ignored.
o Port (2 octets) - Value specifying an associated port. A value
of zero means that the Port field should be ignored.
o Identification Data (variable length) - Value, as indicated by
the Identification Type.
4.6.2.1 Identification Type Values
The following table lists the assigned values for the Identification
Type field found in the Identification Payload.
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
For types where the ID entity is variable length, the size of the ID
entity is computed from size in the ID payload header.
When an IKE exchange is authenticated using certificates (of any
format), any ID's used for input to local policy decisions SHOULD be
contained in the certificate used in the authentication of the
exchange.
4.6.2.2 ID_IPV4_ADDR
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
4.6.2.3 ID_FQDN
The ID_FQDN type specifies a fully-qualified domain name string. An
example of a ID_FQDN is, "foo.bar.com". The string should not
contain any terminators.
Piper Standards Track [Page 20]
RFC 2407 IP Security Domain of Interpretation November 1998
4.6.2.4 ID_USER_FQDN
The ID_USER_FQDN type specifies a fully-qualified username string, An
example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should
not contain any terminators.
4.6.2.5 ID_IPV4_ADDR_SUBNET
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
represented by two four (4) octet values. The first value is an IPv4
address. The second is an IPv4 network mask. Note that ones (1s) in
the network mask indicate that the corresponding bit in the address
is fixed, while zeros (0s) indicate a "wildcard" bit.
4.6.2.6 ID_IPV6_ADDR
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
address.
4.6.2.7 ID_IPV6_ADDR_SUBNET
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
represented by two sixteen (16) octet values. The first value is an
IPv6 address. The second is an IPv6 network mask. Note that ones
(1s) in the network mask indicate that the corresponding bit in the
address is fixed, while zeros (0s) indicate a "wildcard" bit.
4.6.2.8 ID_IPV4_ADDR_RANGE
The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses,
represented by two four (4) octet values. The first value is the
beginning IPv4 address (inclusive) and the second value is the ending
IPv4 address (inclusive). All addresses falling between the two
specified addresses are considered to be within the list.
4.6.2.9 ID_IPV6_ADDR_RANGE
The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses,
represented by two sixteen (16) octet values. The first value is the
beginning IPv6 address (inclusive) and the second value is the ending
IPv6 address (inclusive). All addresses falling between the two
specified addresses are considered to be within the list.
4.6.2.10 ID_DER_ASN1_DN
The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1
X.500 Distinguished Name [X.501] of the principal whose certificates
are being exchanged to establish the SA.
Piper Standards Track [Page 21]
RFC 2407 IP Security Domain of Interpretation November 1998
4.6.2.11 ID_DER_ASN1_GN
The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1
X.500 GeneralName [X.509] of the principal whose certificates are
being exchanged to establish the SA.
4.6.2.12 ID_KEY_ID
The ID_KEY_ID type specifies an opaque byte stream which may be used
to pass vendor-specific information necessary to identify which pre-
shared key should be used to authenticate Aggressive mode
negotiations.
4.6.3 IPSEC Notify Message Types
ISAKMP defines two blocks of Notify Message codes, one for errors and
one for status messages. ISAKMP also allocates a portion of each
block for private use within a DOI. The IPSEC DOI defines the
following private message types for its own use.
Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192
Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
Notification Status Messages MUST be sent under the protection of an
ISAKMP SA: either as a payload in the last Main Mode exchange; in a
separate Informational Exchange after Main Mode or Aggressive Mode
processing is complete; or as a payload in any Quick Mode exchange.
These messages MUST NOT be sent in Aggressive Mode exchange, since
Aggressive Mode does not provide the necessary protection to bind the
Notify Status Message to the exchange.
Nota Bene: a Notify payload is fully protected only in Quick Mode,
where the entire payload is included in the HASH(n) digest. In Main
Mode, while the notify payload is encrypted, it is not currently
included in the HASH(n) digests. As a result, an active substitution
attack on the Main Mode ciphertext could cause the notify status
message type to be corrupted. (This is true, in general, for the
last message of any Main Mode exchange.) While the risk is small, a
corrupt notify message might cause the receiver to abort the entire
negotiation thinking that the sender encountered a fatal error.
Piper Standards Track [Page 22]
RFC 2407 IP Security Domain of Interpretation November 1998
Implementation Note: the ISAKMP protocol does not guarantee delivery
of Notification Status messages when sent in an ISAKMP Informational
Exchange. To ensure receipt of any particular message, the sender
SHOULD include a Notification Payload in a defined Main Mode or Quick
Mode exchange which is protected by a retransmission timer.
4.6.3.1 RESPONDER-LIFETIME
The RESPONDER-LIFETIME status message may be used to communicate the
IPSEC SA lifetime chosen by the responder.
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (var)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
cookies) or four (4) (one IPSEC SPI)
o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3)
o SPI - set to the two ISAKMP cookies or to the sender's inbound
IPSEC SPI
o Notification Data - contains an ISAKMP attribute list with the
responder's actual SA lifetime(s)
Implementation Note: saying that the Notification Data field contains
an attribute list is equivalent to saying that the Notification Data
field has zero length and the Notification Payload has an associated
attribute list.
4.6.3.2 REPLAY-STATUS
The REPLAY-STATUS status message may be used for positive
confirmation of the responder's election on whether or not he is to
perform anti-replay detection.
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (4)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP
cookies) or four (4) (one IPSEC SPI)
o Notify Message Type - set to REPLAY-STATUS
o SPI - set to the two ISAKMP cookies or to the sender's inbound
IPSEC SPI
o Notification Data - a 4 octet value:
Piper Standards Track [Page 23]
RFC 2407 IP Security Domain of Interpretation November 1998
0 = replay detection disabled
1 = replay detection enabled
4.6.3.3 INITIAL-CONTACT
The INITIAL-CONTACT status message may be used when one side wishes
to inform the other that this is the first SA being established with
the remote system. The receiver of this Notification Message might
then elect to delete any existing SA's it has for the sending system
under the assumption that the sending system has rebooted and no
longer has access to the original SA's and their associated keying
material. When used, the content of the Notification Data field
SHOULD be null (i.e. the Payload Length should be set to the fixed
length of Notification Payload).
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (0)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
o Notify Message Type - set to INITIAL-CONTACT
o SPI - set to the two ISAKMP cookies
o Notification Data - <not included>
4.7 IPSEC Key Exchange Requirements
The IPSEC DOI introduces no additional Key Exchange types.
5. Security Considerations
This entire memo pertains to the Internet Key Exchange protocol
([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -