Yoav Nir writes:
> What I could not find anywhere in the RFC is how to match name in
> the ID payload to the certificate. In HTTPS we have a requirement
> that either the CN or the dNSName alternate name match the domain
> name in the URL. We don't have similar rules for IKE, do we?
That is mostly local matter for the CA, cert user and the
configuration of the devices. As Valery already pointed out the
RFC4945 gives some minimum requirements what implementations need to
do.
Implementations are free to whatever they feel like to match those
rules, for example they might support matching against the sub CAs, or
do LDAP lookup or database based on the ID send by the the other end,
and then get rules how the cert is matched against the ID.
The section 3.5 of the RFC5996 says:
----------------------------------------------------------------------
3.5. Identification Payloads
The Identification payloads, denoted IDi and IDr in this document,
allow peers to assert an identity to one another. This identity may
be used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions.
...
The Peer Authorization Database (PAD) as described in RFC 4301
[IPSECARCH] describes the use of the ID payload in IKEv2 and
provides a formal model for the binding of identity to policy in
addition to providing services that deal more specifically with the
details of policy enforcement. The PAD is intended to provide a
link between the SPD and the IKE Security Association management.
See Section 4.4.3 of RFC 4301 for more details.
----------------------------------------------------------------------
And the section 4.4.3 in RFC4301 has even more text about that.
> Of course, looking at RFC 5280, we have all sorts of alternate names
> that look suspiciously useful: otherName, rfc822Name, dNSName,
> directoryName, iPAddress. But it is not immediately obvious:
>
> 1. Is it enough for the ID payload to match the alternate name?
> 2. Is it enough for an ID_FQDN to match the CommonName of a
> certificate subject?
> 3. Is it enough for an ID_DER_ASN1_DN to match the certificate subject?
Depending on the policy yes.
> 4. Is it enough if the ID_IPV*_ADDR matches the source IP of the IKE packet?
In the RFC5996 section 3.5 it says:
----------------------------------------------------------------------
When using the
ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
does not require this address to match the address in the IP header
of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
of IDi/IDr are used purely to fetch the policy and authentication
data related to the other party.
----------------------------------------------------------------------
Meaning that the IKEv2 implementation might check that, but that check
is not required, and depending on the policy and setup it might or
might not be done. In most cases it is not useful to do that check, as
it does not provide any information. The ID is used to fetch and check
the authentication information, i.e. if shared key is found based on
the ID and the other end proofs it knows it, that is enough to
identify the other end, even if the packets didn't come from that
source address. This kind of setup might be useful setup in some
environments, for example the enterprice adminstrators might assign
each laptop a unique 10.0.x.y address for inside company use, and
create certificate or shared key for that specific address. When using
the laptop inside the company network the IP address and the ID
matches, but when the device is away from the company network it might
still be useful to use same ID when connecting the VPN gateway, or
servers in the company network, even when the outer IP address might
be something completely different.
> I've looked in RFC 4301 and found this in section 4.4.3.2:
> This document does not require that the IKE ID asserted by a peer be
> syntactically related to a specific field in an end entity
> certificate that is employed to authenticate the identity of that
> peer. However, it often will be appropriate to impose such a
> requirement, e.g., when a single entry represents a set of peers each
> of whom may have a distinct SPD entry.
>
> The reason this came up in the context of AD-VPN, is that unlike
> "static" VPN, in AD-VPN the PAD is populated dynamically, so while
> we can manually configure a static VPN implementation that to assert
> identity "foo", a peer must present a certificate with value "baz"
> and field "bar", we'd need to either copy that rule to other peers
> in AD-VPN (regardless of which solution, btw), or we'd need a good
> rule.
In the AD-VPN I would expect this kind of things depended a lot about
the environment. In some cases the certificates are already there, so
they cannot put anything there, thus the AD-VPN implementation needs
to be flexible enough to be able to create rules based on that.
In some cases the certificates are created on the fly, or specifically
for the AD-VPN, so the AD-VPN can dictate what needs to be put and
where in the cert, so they will match the policy.
> 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?
No. The rules are already there in the RFC5996, it says they must
match somehow, and leave the details for the different
implementations.
This is not an interoperability issue for the IKEv2. The PKI profile
for IKEv2 gives some minimum requirements that implementations should
do, but implementations quite often will do more than just that.
If AD-VPN has some specific requirements that are not in the PKI
profile for IKEv2 then AD-VPN specification should include those
requirements. On the other hand I would expect that different use
cases might need different kind of requirements, so I do not expect it
to be that simple to put out the exact rules. It might be easy to
provide couple of different set of rules which might be needed, but I
would still expect that in some cases some implementations might want
to implement even more...
On the other hand in the AD-VPN this might be interoperability issue,
as if the other end does not know what kind of PAD entry it should
create, then they cannot talk to each other.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
