Subject: [IPsec] Matching certificates in IKEv2

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Sep 2013 13:45:57 +0000

Hi 

While working on some text for the AD-VPN document, I came across some weirdness in the base IKEv2 specification:

The IDi and IDr payloads have any of several types: ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID.

Section 4 (conformance requirements) says that implementations MUST support "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.".

Section 2.15 (authentication of the IKE SA has the following paragraph:
   Optionally, messages 3 and 4 MAY include a certificate, or
   certificate chain providing evidence that the key used to compute a
   digital signature belongs to the name in the ID payload.

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?

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?
 4. Is it enough if the ID_IPV*_ADDR matches the source IP of the IKE packet?

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.

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?

Yoav

---

From: Srivatsan Raghavan <[email-masked]>
Date: Sun, 15 Sep 2013 19:58:06 +0530

Hi all

How does a Security Gateway specify the validity or duration of an IP Address via CP ? The INTERNAL_ADDRESS_EXPIRY seems deprecated ?
So if the Security Gateway has a notion of lease time, it just has to go and delete the tunnel when the address expires  and the client sets up the tunnel again and requests for an address again?

Thx
Srivatsan

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 16 Sep 2013 15:02:20 +0400

Hi Yoav,

> 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?

Yes, we do: RFC4945.

> 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.

> Yoav

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Sep 2013 17:14:15 +0300

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:
> 

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. 

> 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.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Sep 2013 17:18:25 +0300

Srivatsan Raghavan writes:
> How does a Security Gateway specify the validity or duration of an
> IP Address via CP ? The INTERNAL_ADDRESS_EXPIRY seems deprecated ? 

It does not. The IP address is valid as long as the IKEv2 SA is valid:

RFC5996 section 3.15.1:

   o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
...
							The requested
      address is valid as long as this IKE SA (or its rekeyed
      successors) requesting the address is valid.  
----------------------------------------------------------------------

> So if the Security Gateway has a notion of lease time, it just has
> to go and delete the tunnel when the address expires and the client
> sets up the tunnel again and requests for an address again?

It can do that, but it might be better to just keep the address
allocation as long as the IKE SA is up and running. If it got that
address from someone else (like from DHCP server or similar), it can
do the automatic renewal of the address when it is about to expire,
and if that fails, only then delete the IKEv2 SA. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Sep 2013 17:22:51 +0300

> It's definitely worth to mention these rules in RFC5996bis, or at least 

I think adding pointer could be useful, I do not think we should go in
to any kind of details about those. Also the RFC4945 is just one
profile document, there can also be others. For example some big
enterprise or goverment might create their own profile setting
different set of rules, and require the implementations they buy to
conform to that profile. Most of this is just what kind of policy
setups and configurations can be done on the implementation, it does
not affect the bits on the wire.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Sep 2013 18:09:54 +0000

>> 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 domai…

Thanks. I usually search for RFCs by the ipsec or ipsecme working groups, and I totally forgot about pki4ipsec.

> 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
            |          |             |          |

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 17 Sep 2013 10:00:14 +0400

> > > rules in rfc5996bis,
> > > or should this be left to AD-VPN solutions. IOW, is such a standard 
> > > rule needed for generic IKE/IPsec?
>

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.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Sep 2013 15:28:22 +0300

Valery Smyslov writes:
> thus ID_KEY_ID is out of scope for RFC4945.

As rfc5996 describes ID_KEY_ID as

"An opaque octet stream that may be used to pass vendor-specific
information necessary to do certain proprietary types of
identification."

I see no problem that it is not in the RFC4945. It is intended for the
vendor-specific information so no standard mapping is provided, vendor
will decide one for it.

> 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.

RFC4945 requires that implementations "MUST be capable of verifying"
the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2
does not require such check. There is no contradiction there.

All of that is mostly because in IKEv1 that check was always done, and
people considered it important to be done. In IKEv2 we realized that
kind of test does not really help, and can cause some problems in some
scenarios, so that check was explictly said not to be required
anymore.

The RFC4945 parts are shared with IKEv1 and IKEv2, thus they set the
same requirements for it, but IKEv2 implementation can be conformant
with both of them, i.e provide option to disable that check, and make
it so that by default the checks are done (to be conformant to
RFC4945), but allow those test to be disabled (as is allowed in the
RFC5996). 

> 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.

Yes adding reference to the RFC4945 might be useful, it was not done
in the RFC4306 as the RFC4945 was not ready at that time. Most likely
we should have added it when doing RFC5996 but we didn't.

Perhaps adding reference to the RFC4945 at the end of section 3.5.
Identification Payloads in the RFC5996bis?
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 17 Sep 2013 17:31:40 +0400

> does not require such check. There is no contradiction there.

RFC4945 requires (MUST) this check to be done by default, treats mismatch as
an error and allows (MAY) to skip this check only for interoperability 
purpose.
Probably not contradiction, but some inconsistency, in my opinion.

> Identification Payloads in the RFC5996bis?

Yes, and some explanation text about inconsistencies between the approaches
to match ID to certificate.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Sep 2013 14:45:59 +0300

> Probably not contradiction, but some inconsistency, in my opinion.

Not really inconsistency, it just means that the RFC4945 profile
requires more features than what is required in IKEv2 in general (i.e.
to be able to do the check, and that check is on by default). So
RFC4945 is bit more strict than RFC5996. RFC4945 is IPsec PKI profile
document so it is intended to limit things more than the basic IKEv2.

If someone writes some IPsec XXX Profile document that might add some
other restrictions, for example such profile might require that 4096
bit RAW RSA keys must be used for all authentication for that XXX
environment. This is again more strict than RFC5996 and there is no
contradiction or inconsistency there.

There are RFC5996 implementations which do not need to implement
RFC4945. 

> to match ID to certificate.

No. I do not think we need such text. RFC5996 text is for general
IKEv2 implementation. RFC4945 text is only for those implementations
which support that RFC, not for all IKEv2 implementations. RFC4945 is
supposed to be stricter than RFC5996.

If there is case where RFC4945 requires operations which are not
allowed by RFC5996 then we do have inconsistancy.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 19 Sep 2013 19:44:36 +0300

I just reread the introduction of RFC 4945 and I don't understand its 
purpose. So I'm not sure it should be referenced from 5996bis.

It is definitely not a "profile" in the sense that Tero is alluding to. 
Tero's own "minimal IKEv2" is a profile for a specific use. RFC 4945 
just attempts to fill in the holes (or perceived holes) in RFC 4306 and 
PKIX docs wrt PKI use in IPsec. Which just happens to be the main use 
case of IKE/IPsec!

Quoting: "This profile of the IKE and PKIX frameworks is intended to 
provide an agreed-upon standard for using PKI technology in the context 
of IPsec by profiling the PKIX framework for use with IKE and IPsec, and 
by documenting the contents of the relevant IKE payloads and further 
specifying their semantics."

Thanks,
	Yaron

>>>> packet by default, while the former explicitely allows not to do it
[...]>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Sep 2013 14:21:15 +0300

> purpose. So I'm not sure it should be referenced from 5996bis.

Ok, if there is any disagreement about it, then I think it is better
to leave it out from 5996bis. 

> PKIX docs wrt PKI use in IPsec. Which just happens to be the main use 

I have understood that RFC4945 is profile which profiles both PKIX and
IPsec, i.e. tell the CA vendors what kind of features might be needed
form the PKIX if certificates are used in the IPsec environment, and
tell the IPsec vendors what kind of certificates it will receive from
the CAs and how those can be used in the IPsec environment.

> specifying their semantics."

This very clearly tells the first part (i.e. the profiling the PKIX),
and bit vaguely describes the second part (i.e. "document the contents
of relevant IKE payloads and further specifying their semantics"
meaning that it profiles the IPsec implementations by specifying more
exact contents and semantics to the payloads, when the IPsec
specifications usually leave them open).

It is profile in such sense that it gives common ground for PKIX and
IPsec vendors so they can agree on what kind of certs can be used in
IPsec.

It is not the only possible way of combining PKIX and IPsec, for
example if someone wants to use certificates and IPsec to protect
routers, the requirements what kind of certificats and what kind of
IKE payloads and their semantics might be different.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 24 Sep 2013 16:04:40 +0400

> to leave it out from 5996bis.

If we leave it out, than original Yoav's question "is there anywhere in the 
RFC
description of how to match ID to certificates" will arise from 
implementers.
And not all of them will be able to find RFC4945 without reference.
So, what's wrong in referencing it, at least as informative reference?

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Sep 2013 13:21:40 +0000

On Sep 24, 2013, at 3:04 PM, Valery Smyslov <[email-masked]> wrote:

> If we leave it out, than original Yoav's question "is there anywhere in the RFC
> description of how to match ID to certificates" will arise from implementers.

It's really worse than just implementers asking questions. As long as there's no definitive profile, any implementer and often any administrator can stuff whatever they want in the certificate, and the other implementations have to deal with it. 

For example, my implementation by default stuffs some internal name into the subject common name, and an IP address of the gateway into an alternate name.  For interop with other gateways, we have this dialog box called "Certificate Matching Criteria" for each peer gateway, where the administrator can specify the subject DN, the IP address (as an alternate name), or an RFC822 name (as an alternate name, not an RDN). And because there is no standard way to map ID payloads to certificate fields, we just ignore them (and have a way to configure what we send for interop).

For the purposes of ADVPN we (different "we" this time) will create our own profile, which is actually a reverse profile - we're not specifying what a certificate should hold, but what the ID payload should hold, given an existing certificate. 

I don't think we have an answer for the general IKEv2 question, though.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Sep 2013 07:00:55 -0700

<no hat>

> to leave it out from 5996bis. 

Please do not. It is flawed, but it is the best we have. If you leave it out, then you will have to reproduce all the valuable matching bits in 5996bis. That's possible, but likely more work than you expect.

> the CAs and how those can be used in the IPsec environment.

Tero's description of what was intended is exactly right. Whether or not we achieved that goal is a different matter.

> IKE payloads and their semantics might be different.

...and therefore cause lack of interop.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Sep 2013 21:12:59 +0300

I'll defer to Paul on this one.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Sep 2013 18:47:20 +0000

Still might be worth a document proposing some profile, even if it does not match current practice.