[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
- [IPsec] Shepherd review of the draft-ietf-ipsecme… Tero Kivinen
- Re: [IPsec] Shepherd review of the draft-ietf-ips… Valery Smyslov
- Re: [IPsec] Shepherd review of the draft-ietf-ips… tirumal reddy
- Re: [IPsec] Shepherd review of the draft-ietf-ips… mohamed.boucadair
- Re: [IPsec] Shepherd review of the draft-ietf-ips… mohamed.boucadair
- Re: [IPsec] Shepherd review of the draft-ietf-ips… mohamed.boucadair
- Re: [IPsec] Shepherd review of the draft-ietf-ips… Tero Kivinen
- Re: [IPsec] Shepherd review of the draft-ietf-ips… Tero Kivinen
- Re: [IPsec] Shepherd review of the draft-ietf-ips… Tero Kivinen
- Re: [IPsec] Shepherd review of the draft-ietf-ips… Valery Smyslov
- Re: [IPsec] Shepherd review of the draft-ietf-ips… mohamed.boucadair
- Re: [IPsec] Shepherd review of the draft-ietf-ips… Tero Kivinen
- Re: [IPsec] Shepherd review of the draft-ietf-ips… mohamed.boucadair