[IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

Tero Kivinen <kivinen@iki.fi> Mon, 30 January 2023 22:40 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43879C1782D0; Mon, 30 Jan 2023 14:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QazJl2CLjQ2m; Mon, 30 Jan 2023 14:40:30 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A5BC17D685; Mon, 30 Jan 2023 14:40:28 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id C89CB1B001A6; Tue, 31 Jan 2023 00:40:22 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1675118423; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dHjvVERi62DhPuktm1qopFNoPGz9UxJajtP1viGtw58=; b=HY34hzPD5A/NT5xFvDbDfvom5s44PtDiD5JFwp+ZsHRGcEZKU6DBKqDQhhojIPfKF6w3u2 9J+5F2v5C1ysWutJ+t2lNuEgnijPaG9gfcGTfEmYQhwf5byvwgeALrPX4ghHl7r6Xt87NC vAMLtQMaNrVnWSiiYS6puYBahRGzK/DVmB60lyvQ/JG+4/garf798yIPckdu0zLqlmGQmr FqKwKN1Wfj3qpSoDhuNK/jOws93MFJ/MaZdHK/Y/UxNMkLku1BrSiDfqOOk4CAoKUHW4la vxhfVRnY6Fs1azGGu/AwqwcjxkZS6iehapdttB7/GyQQHRF3EGCb8Vj4qqJv3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1675118423; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dHjvVERi62DhPuktm1qopFNoPGz9UxJajtP1viGtw58=; b=ilFa6jxGwtVPNiCYmJzqlxkKWduxwjJf6owPomlttDQD/FaEQEQpBtAf7mu5NqsPA587Sg yI+pcmHC7j28a23QxSWO0B1MxoAcBRp/jE8GRHIFX0krhZz006BbkbEaVJBTAQ/3ixJcjO lYa+UNbHsLmigFwFv/aGLyDs2EcaGMITmZc2UilhDU5YlphuSZ3x97skecqNf9aSfM6Enl p3FPTor4ytWX4tgy1j1u2TGUMZugI2LkkwowUDEDkWArHBw8nwzf+s5wWmuN/4rtmtiQgN omk+NUIbvONw7Lbf1o1qylHAD50Uet6BpPMfi4GsUcNM7rk0WMXZaG7B8KD/IQ==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1675118423; a=rsa-sha256; cv=none; b=E4vLItgl1gSlmG6N35aRIdKhWiLsNRKga+YT0n46QNZ6bAHSG8+cH2NaPDkDrSn4U9jSwM Sle4F4JELIgtUDRiLaD0pzjPSZWYKXi4mWpOwiudgDKJCImNJHtOZ1w0bxDkzp3eL7qST8 6Wvb3Q6BBIlSriNOpw4ILWQVXTxDBswku58uVMuPGq/l80VQ6EtL6lzWl2tn62L2lABQqU EyWHkH0Da/K4mP/zUqFvhHWahuRvDrV9LO8yHv0fLhtGj2Y0Jdx8Tzt4pIoHjunheiYvPq AeWt+ZPSaGd/qctnXfIWHvuBXEmVQBF1ApFPL+GqDDRaEUxdXgmz42ftTsrFPQ==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 3086325C1300; Tue, 31 Jan 2023 00:40:22 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25560.18262.145478.996578@fireball.acr.fi>
Date: Tue, 31 Jan 2023 00:40:22 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: draft-ietf-ipsecme-add-ike@ietf.org
Cc: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 49 min
X-Total-Time: 74 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/8-NcOjbBTk08lCHyYuU0zV5v_uM>
Subject: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2023 22:40:36 -0000

Here are some my review comments while reading
draft-ietf-ipsecme-add-ike:

----------------------------------------------------------------------
The text in section 3.1 should say that if length is 0, then no
Service Priority, Num Addresses etc fields are present.

I.e., add text in first bullet under Length saying that if length is
zero, then later fields are not present.

--

Also the text in Num Addresses indicate that it would be valid to send
CFG_REQUEST with proposed Service Priority, but having Num Addresses
set to zero?

Is this intended? I.e., is the client allowed to request data, but not
propose IP address? If so, perhaps add sentence to Num Addresses
explaining that it can be 0 for CFG_REQUEST when no specific address
is request, but other parameters are requested.

--

In IP Address(es) explictly mention that it is field contain 4 octet
IPv4 addresses, or 16 octet IPv6 address without any delimeters etc.
This can be derived from the calculation of the length field, but I
think it should be mentioned here, even when it is obvious.

--

In section 3.2 it is not clear what the length of the Hash Algorithm
Identifiers fields is. It contains list of hash algorithms or one hash
algorithm if this is response, but it is not clear what is response.

We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely
CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other
hand CFG_SET is usually used to set the parameters, thus the
Certificate Digest would be required there.

I would assume that there is only one Hash Algorithm Identifier for
CFG_REPLY and CFG_SET, and then the Certificate Digest field is
present. For CFG_REQUEST the Hash Algorithm Identifier is a list of
two octet hash algorithm identifiers and the Certificate field is
omitted. For the CFG_ACK only first 4 octets are included and Length
is set to zero.

I think it would be better to split the Figure 2 to three different
figures:


                        1                   2                   3
    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
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-----------------------------+---------------+---------------+
   |                    RESERVED                   |  ADN Length   |
   +-----------------------------------------------+---------------+
   ~                  Authentication Domain Name                   ~
   +---------------------------------------------------------------+
   ~              Hash Algorithm Identifier (2 octets)             ~
   +---------------------------------------------------------------+
   ~                     Certificate Digest                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 2: ENCDNS_DIGEST_INFO Attribute Format for CFG_REPLY and CFG_SET



                        1                   2                   3
    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
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-----------------------------+---------------+---------------+
   |                    RESERVED                   |  ADN Length   |
   +-----------------------------------------------+---------------+
   ~                  Authentication Domain Name                   ~
   +---------------------------------------------------------------+
   ~              List of Hash Algorithm Identifiers               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST

                        1                   2                   3
    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
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK.

and then explain the Hash Algorithm Identifier and List of Hash
Algorithm Identifiers separately.

Actually is there any point of having ADN Length and Authenticated
Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes
with certain domain names with different hash algorithms? Perhaps we
should define the format for CFG_REQUEST as follows:


                        1                   2                   3
    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
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-------------------------------+-------------------------------+
   ~              List of Hash Algorithm Identifiers               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST


--

In section 4 there is text:

   If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the DNS
   client has to create a digest of the DNS resolver certificate
   received in the TLS handshake using the negotiated hash algorithm in
   the ENCDNS_DIGEST_INFO attribute.

But this does not specify how the digest of the DNS resolver
certificate is calculated. There are multiple ways of doing this (only
Subject Public Key Info element like RFC7296 or SPKI(1) selector field
of RFC7671, or full certificate like Cert(0) selector field of
RFC7671).

I would prefer the SPKI (Subject Public Key Info) selector field way
of RFC7671, as then it does not matter if the certificate is renewed
etc.

--

I do not think the [Hash] is normative reference. I did not need to
read and understand that to somewhat understand this document :-)

--

IANA-IKE is bit misleading reference name when you are actually
refering to the IKEv2 Configuration Payload Attribute Types. Perhaps
using IANA-IKE-HASH for the [Hash] above, and IANA-IKE-CFG for this.

--

It would actually be useful to have example configuration for some of
the deployment scenarios in Appendix A, similar than in 3.15.2 of
RFC7296.

i.e.,

  CP(CFG_REQUEST) =
    INTERNAL_IP6_ADDRESS()
    INTERNAL_IP6_DNS()
    ENCDNS_IP6()
    ENCDNS_DIGEST_INFO(0, "", (SHA2-256, SHA2-384, SHA2-512))

and getting reply

  CP(CFG_REPLY) =
    INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
    ENCDNS_IP6(23, 1, 16,
               (2001:DB8:99:88:77:66:55:44),
    	       "doh1.example.com",
	       "???")
    ENCDNS_DIGEST_INFO(0, "", SHA2-256,
                       00112233445566778899aabbccddeeff)

where the data in ECNDNS_IP6 is in the same order they are in the
actual packet, i.e., 23 is the Service Priority, 1 is num address, 16
is ADN Length and then is list of IPv6 addresses and so on.

I for example have no idea what could be in the Service Parameters
field for some specific service (for example DoH), and how it would be
different for DoT...
-- 
kivinen@iki.fi