1 - 2 - 3 - 6 - 8 - 9 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
IKE
Click on the red underlined text to get to the source
... data confidentiality
and authentication services, and IKE as the key management protocol.
iFCP ...
... data confidentiality
and authentication services, and IKE as the key management protocol.
FCIP ...
... IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE
is the key management protocol while AH ...
... values.
IKE is a two phase negotiation protocol based on the modular exchange
of messages defined by ISAKMP ...
... Domain of
Interpretation (DOI) [RFC2407]. IKE has two phases, and accomplishes
the following functions:
...
... rekeying)
Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is
handled in IKE Phase 2.
...
... Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is
handled in IKE Phase 2.
An IKE ...
... IKE Phase 2.
An IKE Phase 2 negotiation is performed to establish both an inbound
and an outbound IPsec ...
... IPsec SA
is determined by a selector which has been proposed by the IKE
initiator and accepted by the IKE ...
... port, Destination port>.
The successful establishment of a IKE Phase-2 SA results in the
creation of two uni-directional IPsec ...
... Note that requirements specified in this document apply only to use
of IPsec and IKE with IP block storage protocols. Thus, these
requirements ...
... authentication mechanisms or the authentication provided by
IKE) in order to provide a minimal assurance that connections have
initially been opened with the intended counterpart.
...
... IKE ...
... Conformant IP block storage security implementations MUST support IKE
[RFC2409] for peer authentication ...
... authentication using the public key
encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409]
SHOULD NOT be used.
...
... Conformant IP block storage security implementations MUST support IKE
Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with
...
... security implementations MUST support IKE
Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with
pre-shared key authentication SHOULD NOT be used when either of the
...
... When digital signatures are used for authentication, either IKE Main
Mode or IKE Aggressive Mode MAY be used. In all cases, access to
...
... authentication, either IKE Main
Mode or IKE Aggressive Mode MAY be used. In all cases, access to
locally stored secret information (pre-shared key ...
... When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload ...
... authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify
the certificate authority ...
... certificate authority (or authorities) that are trusted in
accordance with its local policy. IKE negotiators SHOULD check the
pertinent Certificate Revocation List (CRL ...
... IPsec DOI [RFC2407] provides for several types of identification
data. Within IKE Phase 1, for use within the IDii and IDir payloads,
conformant IP ...
... hardware may only be able to handle a
limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
...
... active
Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete
message MUST NOT be interpreted as a reason for tearing down an IP
...
... connection up, and if additional traffic is sent on it, to bring up
another IKE Phase 2 SA to protect it. This avoids the potential for
continually bringing connections ...
... interoperability without requiring extensive configuration. This
section provides guidelines on setting of IKE parameters so as to
enhance the probability of a successful negotiation. It also
...
... If a key lifetime is offered that is longer than desired, then
rather than causing the IKE negotiation to fail, it is
recommended that the Responder ...
...
It may also be helpful to obtain information about the preferences of
the peer prior to initiating IKE. While it is generally possible to
negotiate security parameters within IKE ...
... IKE. While it is generally possible to
negotiate security parameters within IKE, there are situations in
which incompatible parameters can cause the IKE negotiation ...
... security parameters within IKE, there are situations in
which incompatible parameters can cause the IKE negotiation to fail.
The following information can be provided via SLPv2 ...
... endpoint requires IPsec or cleartext. This
cannot be determined from the IKE negotiation alone without
risking a long timeout, which is highly undesirable for a disk
...
... PFS) support.
It is helpful to know whether a peer allows PFS, since an IKE
Phase 2 Quick Mode can fail if an initiator ...
... transport and tunnel mode
within the same offer, not all IKE implementations will support
this. As a result, it is useful to know whether a peer prefers
tunnel mode ...
...
[7] Main Mode and Aggressive Mode support.
Since the IKE negotiation can fail if a mode is proposed to a
peer that doesn't allow it, it is helpful to know which modes a
...
... section 8.3.2) MUST be used to protect the connection. Moreover, in
this case IKE authentication with group pre-shared keys ...
... initiators and targets may enable IKE mechanisms to establish
identity. In addition, a subsequent user-level ...
... FCIPSLP]. FCIP Entities
assume that once the IKE identity of a peer is established, the FCIP
...
... digital signatures are used to
achieve authentication in IKE, an IKE negotiator SHOULD use IKE
...
... authentication in IKE, an IKE negotiator SHOULD use IKE
Certificate Request Payload(s) to specify the certificate authority ...
... (or authorities) that are trusted in accordance with its local
policy. IKE negotiators SHOULD check the pertinent Certificate
Revocation List (CRL) before accepting a PKI ...
... UA might be allowed to use
any certificate conforming to IKE certificate policy, the certificate
...
... certificate authorized for SLPv2 DAAdverts in establishing the
IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no
...
... authorized hosts, include use or non-use of IPsec, IKE, Main Mode,
Aggressive Mode, PFS, Pre-shared Key ...
... certificates.
For example, IKE may not be enabled for a particular device
interface. If a peer device can learn of this in advance by
consulting the iSNS server, it will not need to waste time and
...
... device
interface. If a peer device can learn of this in advance by
consulting the iSNS server, it will not need to waste time and
resources attempting to initiate an IKE Phase 1 SA with that device
interface.
...
... security policy, then the minimum
information that should be learned from the iSNS server is the use or
non-use of IKE and IPsec by each iFCP or iSCSI ...
... iSCSI device
can be stored in the iSNS server, including policies that are used
for IKE Phase 1 and Phase 2 negotiations between client devices. The
IKE ...
... IKE Phase 1 and Phase 2 negotiations between client devices. The
IKE payload format includes a series of one or more proposals that
the iSCSI ...
... security policy via iSNS.
For further details on how to store and retrieve IKE policy proposals
in the iSNS server, see [iSNS].
...
... NULL Encryption MUST be used.
Conformant iSNS implementations MUST support IKE for authentication,
negotiation ...
... and 5.3 SHOULD NOT be used.
Conformant iSNS implementations MUST support IKE Main Mode and SHOULD
support Aggressive Mode. IKE Main Mode with pre-shared key
authentication ...
... Conformant iSNS implementations MUST support IKE Main Mode and SHOULD
support Aggressive Mode. IKE Main Mode with pre-shared key
authentication SHOULD NOT be used when either of the peers use
dynamically assigned IP addresses ...
... When digital signatures are used for authentication, either IKE Main
Mode or IKE Aggressive Mode MAY be used. In all cases, access to
...
... authentication, either IKE Main
Mode or IKE Aggressive Mode MAY be used. In all cases, access to
locally stored secret information (pre-shared key ...
... When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload ...
... authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify
the certificate authority ...
... certificate authority (or authorities) that are trusted in
accordance with its local policy. IKE negotiators SHOULD check the
pertinent Certificate Revocation List (CRL ...
... The relationship between iSCSI sessions, TCP connections and IKE
Phase 1 and Phase 2 SAs is as follows:
...
... IP
address. As a result, an iSCSI Session may correspond to
multiple IKE Phase 1 Security Associations, though typically a
single IKE ...
... IKE Phase 1 Security Associations, though typically a
single IKE Phase 1 security association will exist for an
<initiator ...
... TCP connection within an iSCSI Session is protected by an
IKE Phase 2 SA. The selectors may be specific to that TCP
connection or may cover multiple connections ...
... Phase 2 SA. The selectors may be specific to that TCP
connection or may cover multiple connections. While each IKE
Phase 2 SA may protect multiple TCP connections ...
... Phase 2 SA may protect multiple TCP connections, each TCP
connection is transported under only one IKE Phase 2 SA.
...
... and target. This includes the binding between an IKE Phase 1 SA and
the corresponding iSCSI sessions ...
... In order to create a new iSCSI Session, if an IKE Phase 1 SA does not
already exist, then it is established by an initiator ...
... iSCSI connections established within the
iSCSI session will typically be protected by IKE Phase 2 SAs derived
from that IKE ...
... initiator and target implementations successfully complete the
IKE Phase 1 and Phase 2 negotiations before the iSCSI initiator
...
... A single iSCSI session identifier may have multiple associated IKE
Phase 1 SAs, and each IKE ...
... IKE
Phase 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI
session identifiers ...
... identifier) corresponds to a single TCP connection
(identified by the 5-tuple). Each IKE Phase 2 SA is identified by
the <Protocol (ESP ...
... Phase
2 SA may protect multiple TCP connections, and corresponds to a
single IKE Phase 1 SA.
...
... TCP connection unexpectedly fails, the associated iSCSI
connection is torn down. There is no requirement that an IKE Phase 2
delete immediately follow iSCSI connection ...
... delete immediately follow iSCSI connection tear down or Phase 1
deletion. Since an IKE Phase 2 SA may correspond to multiple TCP
connections, such a deletion might be inappropriate. Similarly, if
...
... Phase 2 SA may correspond to multiple TCP
connections, such a deletion might be inappropriate. Similarly, if
the IKE implementation receives a Phase 2 Delete message for a
security association ...
... hardware may only be able to handle a
limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
...
... active
Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete
message MUST NOT be interpreted as a reason for tearing down the
corresponding iSCSI connection ...
... iSCSI connection up, and if additional traffic is sent on
it, to bring up another IKE Phase 2 SA to protect it. This avoids
the potential for continually bringing iSCSI connections ...
...
A conformant iFCP Portal is capable of establishing one or more IKE
Phase-1 Security Associations (SAs ...
... same iFCP Portal. More specifically, the successful establishment of
an IKE Phase-2 SA results in the creation of two uni-directional
IPsec ...
... In summary, at any point in time:
[1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals ...
... To minimize the number of active Phase-2 SAs, IKE Phase-2 delete
messages may be sent for Phase-2 SAs whose TCP connections ...
... FCIP endpoint IP Addresses are different. In this case, an IKE
Phase 1 SA is typically established for each FCIP ...
... endpoint IP Address
pair. For the purposes of establishing an IKE Phase 1 SA, static IP
addresses are typically used for identification.
...
... IPsec tunnel mode servers
typically implement this functionality via proprietary extensions to
IKE.
...
... IKE Issues ...
...
There are situations where it is necessary for IKE to be implemented
in firmware. In such situations, it is important to keep the size of
the IKE implementation ...
... IKE to be implemented
in firmware. In such situations, it is important to keep the size of
the IKE implementation within strict limits. An upper bound on the
size of an IKE implementation might be considered to be 800 KB, with
...
... the IKE implementation within strict limits. An upper bound on the
size of an IKE implementation might be considered to be 800 KB, with
80 KB enabling implementation in a wide range of situations.
...
... wide range of situations.
As noted in Table 5.3-1 on the next page, IKE implementations
currently exist which meet the requirements. Therefore, while
...
... currently exist which meet the requirements. Therefore, while
removal of seldom used IKE functionality (such as the nonce
authentication methods ...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 5.3-1 - Code Size for IKE implementations
The formula below sets a limit on the bytes that can be sent on a CBC ...
... When certificate authentication is used, IKE fragmentation can be
encountered. This can occur when certificate chains ...
... that can be compared against an Access List.
As a result, where IKE fragmentation occurs, the endpoints will often
...
... IP block storage protocols, each TCP connection MUST
be protected by an IKE Phase 2 SA. Traffic from one or more than one
...
...
Use of pre-shared keys in IKE Main Mode is vulnerable to man-in-the-
middle attacks when used with dynamically addressed hosts ...
... initiator
nor Responder identifies itself during IKE Phase 1; it is only known
that both parties are a member of the group with knowledge of the
...
... FCIP), since in this situation
individual pre-shared keys are possible within IKE Main Mode.
However, where IP addresses ...
... often considered undesirable.
Note that care needs to be taken with IKE Phase 1 Identity Payload
selection in order to enable mapping of identities to pre-shared keys ...
... With IPsec, when the identity asserted in IKE is authenticated, the
resulting derived keys are used to provide per-packet ...
... replay protection. As a result, the identity verified
in the IKE conversation is subsequently verified on reception of each
packet.
...
... Login is a user
identity, while the identity claimed within IKE is a machine
identity. Since only the machine identity ...
...
While the identity asserted within IKE is verified on a per-packet
basis, to avoid interference between users on a given machine,
...
... initiator.
Note that because IKE does not deal well with certificate chains, and
is typically configured with a limited set of trusted roots ...
... Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409(-> 4306prop), November 1998. ...
... Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002. ...