FCIP WG Last Call - Security Comments Proposed Resolutions

[Ralph Weber <ralphoweber@compuserve.com>]

http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-00.pdf

Contain the proposed resolutions shown below for technical comments
related to security.

If you want to discuss any of the proposed resolutions please
start a new reflector message thread for each comment to be
discussed and include the comment number in the message subject.

Thanks.

.Ralph

1. Comments from David Black
   =========================

Comment 62 Technical

   -- Section 10 Security

   [T] Need to get this whole section aligned with the latest (currently
   -11) version of the IPS Security draft.

   Accepted with the following results

   Section 10 will be aligned with IPS Security Draft version 12.
   This will require a substantial number of changes, as detailed
   below. It would be desirable to avoid a "hairball" between FCIP
   and the IPS Security Draft. With this in mind, it is believed that
   changes in the IPS Security Draft will concern areas that do not
   directly impact FCIP. Of course, there are no guarantees.

   In Section 10.1, add the following to the Threat Models: "8) An
   adversary may launch a variety of attacks against the discovery
   process [SLPv2, RFC2608]."

   Note: This addition is placed in the list in such a way as to keep
   the FCIP-specific attack (the attack related to the Special Frame)
   last in the list.

   Section 10.3.1, add the following to the end of the first paragraph:
   "When ESP is utilized, per-packet data origin authentication,
   integrity and replay protection must be used."

   In addition to the changes in Section 10.3.2 (Key Management)
   described in comment 69, comment 70, comment 71, comment 72, and
   comment 73, make the following changes:

   1) Add the following to the end of Paragraph 1:

      "Conformant FCIP implementations MUST support peer authentication
      using pre-shared key and MAY support peer authentication using
      digital certificates. Peer authentication using public key
      encryption methods outlined in IKE [2409] Section 5.2 and 5.3
      SHOULD NOT be used."

   2) Change the last sentence of Paragraph 2 from:

      "FCIP Entities MUST support "Main Mode" operation in Phase 1 and
      MAY support "Aggressive Mode" if identity protection is not
      required."

      to:

      "FCIP implementations MUST support IKE Main Mode and SHOULD
      support Aggressive Mode."

   3) Add the following at the end of paragraph 3: "The Phase 2 Quick
      Mode exchanges MUST explicitly carry the Identity Payload fields
      (IDci and IDcr). Each Phase 2 payload SHOULD carry a single IP
      Address and a single non-zero port number and SHOULD NOT use the
      IP Subnet or IP Address Range formats. Other ID payload formats
      MUST NOT be used."

   4) Add the following new paragraph after paragraph 3: "Since the
      number of Phase 2 SAs may be limited, Phase 2 delete messages may
      be sent for idle SAs. The receipt of a Phase 2 delete message
      SHOULD NOT be interpreted as a reason for tearing down an FCIP
      Link or any of its TCP connections. When there is new activity on
      that idle link, a new Phase 2 SA MUST be re-established."

   5) In the paragraph that starts with "For the purposes of...",
      change the last sentence from:

      "For the purposes of establishing IKE Phase 1 SA, static IP
      Addresses are typically used for identification."

      to:

      "Within IKE Phase 1, FCIP implementations must support the
      ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6)
      and ID_FQDN Identity Payloads. If FCIP Endpoint addresses are
      dynamically assigned, it may be beneficial to use ID_FQDN, and
      for this reason, IP_FQDN Identity Payload MUST be supported.
      Other identity payloads (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID)
      SHOULD NOT be used.


Comment 68 Technical

   -- Section 10.3.1 - IPSec ESP Authentication and Confidentiality

      FCIP Entities MUST implement IPSec ESP [16] in Tunnel Mode for
      providing Data Integrity and Confidentiality. FCIP Entities MAY
      implement IPSec ESP in Transport Mode, if deployment considerations
      require use of Transport Mode.

   [T] Those deployment considerations include RFC 2401 requirement for
   Transport mode because the IPsec implementation is a host
   implementation rather than a security gateway. I thought this was
   understood by the FCIP authors, and it needs to be explicit here
   including an appropriate reference to RFC 2401. I expect to be able
   to double-check this requirement with the IETF Security Area in the
   next few days.

   Rejected

   As per the consensus taken at the March 2002 IETF meeting, Transport
   Mode implementation is a MAY.


Comment 71 Technical

   -- Section 10.3.2 - Key Management

      When pre-shared keys are used, IKE Aggressive Mode SHOULD be used
      and Main Mode SHOULD NOT be used.

   [T] I think this is too strong and will cause problems. Pre-Shared
   keys are a "MUST", Aggressive Mode is a "MAY", so this "SHOULD" is
   inconsistent. The issue with Main Mode arises when dynamically
   assigned IP addresses are used (and hence Main Mode can't figure out
   which pre-shared key to use). The escape from this box appears to be
   that Aggressive Mode is a MUST (SHOULD?) when dynamic assignment of
   IP addresses to FCIP implementations is used, but support for dynamic
   assignment of IP addresses is NOT REQUIRED.

   The problem with this approach is that one gets into trouble on one
   end of an FCIP Link when the *other* end has its IP address
   dynamically assigned. The obvious solutions to this issue are to
   forbid (MUST NOT) dynamic IP address assignment (which has no chance
   of making it through the IESG) or to REQUIRE Aggressive Mode (as iFCP
   does). In addition, the IPS Security draft appears to need some
   editing to allow Aggressive Mode to be a "MAY" for FCIP (and iFCP).
   Darn - I thought we had this issue closed in Huntington Beach - did I
   miss something?

   Accepted with the following results

   Replace the cited text with: "When pre-shared keys are used, IKE
   Main Mode is usable only when both peers of an FCIP Link use
   statically assigned IP addresses. When support for dynamically
   assigned IP Addresses is attempted in conjunction with Main Mode,
   use of group pre-shared keys would be forced, and the use of group
   pre-shared keys in combination with Main Mode is not recommended as
   it exposes the deployed environment for man-in-the-middle attacks.
   Therefore, if either peer of an FCIP Link uses dynamically assigned
   address, Aggressive Mode SHOULD be used and Main Mode SHOULD NOT be
   used."


Comment 74 Technical

   -- Section 10.4.2 - TCP Connection Security Associations (SAs)

      For a TCP Connection establishment, IKE Phase 2 is employed,
      resulting in an SA, identified by an SPI. All IP datagrams of the
      TCP Connection MUST carry an ESP header with a valid SPI and
      Sequence Number to be accepted as valid by the receiving peer.

   [T] The requirement for a phase 2 SA per TCP connection has been
   removed. This text (and possibly the rest of this section) need some
   editing to reflect that.

   Accepted with the following results

   1) Replace the cited text with: "Each TCP connection MUST be
      protected by an IKE Phase 2 SA. Traffic from one or more than
      one TCP connection may flow within each IPsec Phase 2 SA. While
      it is possible for a IKE Phase 2 SA to protect multiple TCP
      connections, all packets of a TCP connection is protected using
      only one IKE Phase 2 SA. FCIP implementations need not verify
      that the IP addresses and port numbers in the packet match any
      locally stored per-connection values, leaving this check to be
      performed by the IPsec layer."

   2) Delete the last paragraph of the section, which currently reads:
      "When a TCP Connection is terminated or closed, all SAs
      associated with it MUST be removed from the local SAD."


Comment 76 Technical

   -- Section 10.4.3 - Handling data integrity and confidentiality
    violations

      Confidentiality checks MUST be performed if Confidentiality is
      enabled.

   [T] And what would those be, please? Replace this with a prohibition
   on use of Confidentiality without Integrity.

   Accepted with the following results

   Replace the first "Confidentiality" with "Integrity".


Comment 77 Technical

   -- Section 10.4.4 - Handling SA parameter mismatches

      When SA parameters do not match, the TCP Connection may reach a
      point where no traffic moves, or there are excessive TCP
      retransmissions. In such a case, either side MAY take one of the
      following actions:
      a)  Reestablish another set of SA parameters; or
      b)  Close the TCP Connection and notify the FC Entity with the
          reason for the closure.

   [T/E] Needs some more explanation, including an example of the
   sort of mismatch that could cause this problem. Recall that IKE
   negotiates SA parameters, and this fact needs to be included in the
   explanation and example.

   Accepted but perhaps not as intended

   The handling of SA parameter mismatches belongs in a security draft,
   not in FCIP. Therefore, section 10.4.4 will be removed.