> > So do you think it would be appropriate to mandate these matching
> > rules in rfc5996bis,
> > or should this be left to AD-VPN solutions. IOW, is such a standard
> > rule needed for generic IKE/IPsec?
> It's definitely worth to mention these rules in RFC5996bis, or at least
> point to the RFC4945.
Now that I've seen it, I don't think so. Not without updating it. See RFC
5996 says in section 4:
For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following:
o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN.
Note the ID_KEY_ID. But RFC 4945 says this is section 3.1.7:
The ID_KEY_ID type used to specify pre-shared keys and thus is out of
scope.
And in the table in section 3.1:
ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules
-------------------------------------------------------------------
| | | |
KEY_ID | MUST NOT | n/a | n/a | n/a
| | | |
Yes, there is no obvious mapping between ID_KEY_ID and certificates and
thus ID_KEY_ID is out of scope for RFC4945. And this not the only
contradiction between RFC5996 and RFC4945 - the latter requires
ID_IPV*_ADDR to match source IP address of IKE packet by default,
while the former explicitely allows not to do it in any case.
But I still believe that adding a few words about matching ID to
certificates,
or point to RFC4945 (probably with some explanation text) will still be
useful
for not so experienced RFC readers as the members of this list.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
