Hi,
a couple of comments.
I think that the profile is generally OK, but it seems to me that a few issues
persist.
1. The
Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter
names used in this text.
“PKCS #7 wrapped X.509 certificate” certificate encoding is deprecated and
is not used in IKEv2
(see
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-11).
Generally, I see no need for the text that imposes requirements on
certificate encoding at all –
we never run into the interoperability problems with this? as far as I
remember. I suggest to remove this text.
2. If certificate chains are used, all intermediate certificates up to,
and including the locally provisioned trust anchor certificate MUST
be signaled. See Section 6.10.7 for the sub-CA example in which
certificate chains are used.
This is confusing. I read this text as the “MUST” is imposed only if
“certificate chains are used”. Does it mean that implementations
may skip this “MUST” if EE certificate is directly signed by CA certificate
and there is no intermediate certificates? Or is it still a chain
and “if” is relevant to the case when there is no CA and there is a direct
trust to EE certificates
(in which case PKI is not needed at all and you can use RAW public keys)?
Another point: trust anchors certificates usually are not included in CERT
payload in IKEv2.
I see draft’s a reasoning that this inclusion would allow better network
debugging,
but I’m not sure I can buy this argument. Probably more detailed
explanation is needed.
3. IKEv2 authentication MUST use authentication method 14 ("Digital
Signature") for ACP certificates; this authentication method can be
used with both RSA and ECDSA certificates, as indicated by a PKIX-
style OID.
I think it’s better to rephrase this more accurately: “indicated by an
ASN.1 object AlgorithmIdentifier”
(which may include parameters besides OID).
A typo in the title of 6.7.1.1.2.: s/RFC847/RFC8247
Regards,
Valery.
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Tuesday, February 25, 2020 11:18 PM
To: Toerless Eckert
Cc: ipsec@ietf.org WG; Michael Richardson;
draft-ietf-anima-autonomic-control-pl...@ietf.org
Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control
plane)
Hi, Toerless.
I trimmed below most of your background info.
On 24 Feb 2020, at 21:50, Toerless Eckert <t...@cs.fau.de> wrote:
[hope its fine to cross-post ipsec and ipsecme given how one is concluded, but
may have
more long-time subscribers]
ipsec is this group’s mailing list. I don’t know that there even is an
ipse...@ietf.org
We're looking for opinions about an IPsec profile for "Autonomic Control Plane"
draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of:
https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt
Quick background so you do not need to read anything more than 6.7.1.1.1:
I read a little more. Hope you don’t mind.
The profile seems fine to me. There is one thing that I think is missing.
The profile specifies that the ACP nodes should use tunnel mode (when GRE is
not used), because:
IPsec tunnel mode is required because the ACP will route/forward
packets received from any other ACP node across the ACP secure
channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated
by the ACP node itself.
OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but
that’s not important here) they need an IPsec policy that specifies traffic
selectors so that IKEv2 can specify traffic selectors. Nowhere in your draft
do I see a specification of what traffic selectors need to be negotiated.
If I understand the above paragraph correctly, both the source of the packet
and the destination can be the IP address of any ACP node, neither of which are
required to be the tunnel endpoints. This implies some sort of generic traffic
selector. The draft should specify this, IMO
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
