How I got iked in -current to work with iOS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How I got iked in -current to work with iOS

Theodore Wynnychenko-2
Hi
I had some time today, and decided to send this now.

This is how I got OpenBSD's iked daemon (version in current about 3/28/2021)
to work with Apple's iOS (iphone/ipad's) version (about) 14.4.2.

Some prelude:

So, I have no real reason to do this, other than that I want to.
I think of it as a learning exercise, so my knowledge is limited in many
ways.  I got this to work for my specific use case.

Specially, I only have a few devices that I want/need to have access to my
home's VPN.  I do this to have a secure gateway for access to my
email/calendar/files/etc when not at home (yes, I host my own services - I
know that Apple and Google and other respect my privacy, etc., but ...).

I have NOT tried to set this up as a VPN to route all traffic from
associated devices (I don't have the a connection with the bandwidth
necessary to do so).

Because I am only "managing" a handful of devices, I did all of this
manually.


Limitations/Requirements:

Apple's iOS:

Recently, Apple has put several restrictions on the certificates iOS devices
will accept for ikev2 connections.  These are "disclosed" at
https://support.apple.com/en-us/HT211025 and
https://support.apple.com/en-us/HT210176.

Specifically, certificates must:
- CA and TLS certs using RSA must use key => 2048
- CA and TLS certs must use SHA-2
- TLS certs must have a SubjectAlternativeName with the DNS name of the
server; a CommonName only is not enough

For certificates issued after 7/1/2019:
- ExtendedKeyUsage for TLS server and TLS client must be included
- TLS certs can only be valid for 825 days or less

For certificates issued by the Root CA's preinstalled in iOS, after
9/1/2020:
- TLS certs can only be valid for 398 days or less



OpenBSD's iked:

OpenBSD ikev2 also has some specific requirements for certificate
authentication.

iked requires specific key/authentication combinations:
- rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
- ecdsa256 only supports P-256 with SHA2-256
- ecdsa382 only supports P-384 with SHA2-384
- ecdsa521 only supports P-521 with SHA2-512
- rsa suppors RSA but only with SHA1


Other/General:

In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
that are more generally accepted, and will likely continue to be generally
accepted.  This appears to be based on NIST's inclusion of them in their
"Suite B Cryptography" information.  P-521 was not included in "Suite B,"
and it seems some things have not included support for it.

So, I concluded, to be safe (and since it seems the computational/security
cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
above, to use P-384 with SHA2-384.


My setup:

Certificates:

In order to do this, I used openssl commands directly.  I did not use ikectl
to create certs or the CA.

Before I go into details, I wanted to have certs that would last longer than
the Apple limit.  Therefore, I needed to have a CA certificate, and TLS
certs, that had a "Not Before" date before 7/1/2019.

In order to do this, when I created my CA certificate, I changed the
time/date on the system using "date 201901010000" before creating the CA,
and then reset the date when I was done.

Creating back-dated TLS certs is a bit more direct, all that is necessary is
to add "-startdate 20190102000000Z" to the openssl ca command when signing
the TLS certificate.

Obviously, you need to have complete control of the CA (and not care that
you are doing this) to accomplish this and get certificates with a longer
time horizon for iOS.

So, first I created a CA using ECDSA384:

I created/edited the openssl.cnf file to have the appropriate
additions/defaults I need for these certificates.  I will not cover
everything, but I think these are the basic requirements (I have edited out
many things in the actual file I used, but I THINK what is left is all that
may be really needed, but my openssl knowledge is not absolute, and I may
have errors that I don't realize):

(NOTE:  When I was trying to get this to work, I began to believe that the
current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not use
them.  I now am not sure if "-"'s will work or not.]

General defaults for generating the signing request (csr), openssl.cnf:

default_bits = 4096
default_keyfile = key.pem
default_md = sha384
string_mask = utf8only
distinguished_name = req_distinguished_name
attributes = req_attributes

The distinguished name/attributes are basically from the default cnf file.

For the CA cert, openssl.cnf:

basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
issuerAltName = issuer:copy

For the TLS certs, when creating the signing request, openssl.cnf:

basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
subjectAltName = email:move

For the TLS certs, when signing with CA, openssl.cnf:

default_days = 390 # Most restrictive days for iOS
default_md = sha384
preserve = no
email_in_dn = no
policy = policy_match
copy_extensions = copy
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = DNS:same.as.CN,email:[hidden email]


In the steps that follow, the openssl.cnf file will need to be adjusted to
match each certificate (both CA and TLS) as they are created.

Create a CA key - I did this in two steps here, later only one:

openssl ecparam -name secp384r1 -out secp384r1.param

openssl ecparam -in secp384r1.param -genkey -out ca.ecdsa.key.nopass

I wanted a password for the CA key, so,

openssl ec -aes256 -in ca.ecdsa.key.clear -out ca.ecdsa.key.pem

and then deleted the unencrypted key.

Then, create the CA self-signed certificate:

openssl req -new -x509 -key ca.ecdsa.key.pem -out cacert.pem -days ###
-config openssl.cnf

Now, there is a CA certificate and key with ECDSA384 and SHA2-384.

Create the TLS server cert and key (only one step this time):

openssl ecparam -genkey -name secp384r1 -out server.key

Make the csr:

openssl req -nodes -new -key ikev2.key -out server.csr -config openssl.cnf

Sign the csr with the CA:

openssl ca -in server.csr -out server.pem -config openssl.cnf


Now, create a client cert the same way, but one extra step.
First, create the key, create the CSR, and sign it to get the certificate.

But, this has to be bundled in to a .p12 file for import to iOS:

openssl pkcs12 -export -in client.pem -inkey client.key -CAfile cacert.pem
-out client.p12


Now, there is a cacert.pem (the CA certificate), a server.pem and server.key
(the iked daemon's certificates), and a .p12 with the iOS client's
certificate and key, and the ca certificate (even though I also import the
cacert directly into iOS as a der file).

Move the cacert.pem, server.pem, and server.key into the appropriate places
for iked to find them.



Setup IKED:

If I recall, the PF setup I use just basically follows the guidance in the
man page (I did this years ago).

In my case, it looks like this:

pass in  on $ext_if proto udp from any to $ext.ip port { isakmp, ipsec-nat-t
}
pass out on $ext_if proto udp from $ext.ip to any port { isakmp, ipsec-nat-t
}
pass in  on $ext_if proto udp from any to $local_net port { isakmp,
ipsec-nat-t }
pass out on $ext_if proto udp from $local_net to any port { isakmp,
ipsec-nat-t }

pass in  on $ext_if proto esp from any to $ext.ip
pass out on $ext_if proto esp from $ext.ip to any

pass in  on enc0 proto ipencap from any to $ext.ip keep state (if-bound)
pass out on enc0 proto ipencap from $ext.ip to any keep state (if-bound)

pass in  on enc0 from <ip_ assigned_by_iked> to any keep state (if-bound)
pass out on enc0 from any to < ip_ assigned_by_iked > keep state (if-bound)


I don't use NAT, since I only have a handful of devices, and each gets
assigned a unique IP address by iked.


Each device has its own specific entry in iked, and they look like this:

ikev2 "client_1" passive esp \
        from $local_net to $vpn_net \
        local $local_gw peer any \
        srcid $server_id dstid $client_id \
        ikelifetime 30m lifetime 30m \
        ecdsa384 \
        config address aaa.bbb.ccc.ddd \
        config netmask 255.255.255.0 \
        config name-server aaa.bbb.ccc.111 \
        config name-server aaa.bbb.ccc.222


local_net = my internal network block
vpn_net = network block assigned by iked to clients
local_gw = FQDN of local endpoint
server_id = CN/SAN of server as listed in certificate created
client_id = CN/SAN of client as listed in certificate created

I use iked to give each client a specific and unique IP address, and they
all fall into the "vpn_net" netblock.

I also "config" DNS servers.  But, I don't think iOS accepts these (as I
will get to later), but I never bothered removing them to see if it would
still work.

So, each client has a policy in iked that matches the CN/SAN in its
certificate, and iked also uses the CN/SAN of the server as the srcid for
the policy.


Finally, setting up the iOS client:

In order to do this I use profiles that get imported in the iOS device.

The profiles are generated by Apple Configurator 2 (which requires a Mac),
but then also edited them directly (I will explain why later).

I guess you don't really need the Apple software, as all AC2 does is
generate an XML file.  All the parameters in AC2 (and others that are not
available in AC2) are published by Apple in the "Configuration Profile
Reference."  So, I guess this could be created by hand, but I choose not to.

(I am not looking at the AC2 pages as I type this, so if I make a slight
misstatement, sorry.)

To create the profile, there are three sections to complete.

First, I filled out the mandatory General tab.

In the Certificates tab, I added the cacert.der (I converted the .pem to a
.der for Apple, but I think it would accept the .pem if you change the file
extension to .crt - maybe?) to the profile.

I then added the client.p12 to the profile, also entering the password given
to the .p12 when creating it.

Finally, in the VPN tab, I set up the ikev2 parameters.

Specially:

Connection Type: IKEv2
Server:  FQDN of my server
Remote Identifier:  the CN/SAN from the server certificate
Local Identifier:  the CN/SAN from the client certificate
Machine Authentication:  Certificate
Identity Certificate:  choose the certificate you added
Certificate type:  ECDSA384
Server certificate issuer common name:  CA certificate CN

***** THIS IS REQUIRED *****
***** EVEN THOUGH AC2 LISTS THIS FIELD AS ONLY REQUIRED FOR EAP, THE
REFERENCE GUIDE SPECIFICALLY STATES THAT IT IS REQUIRED WHEN A CERTIFICATE
TYPE IS SELECTED (This was the last thing I changed before getting it to
work - without this set, iOS gives a cryptic "User authentication failed"
error and will not connect, while AT THE SAME TIME, IKED shows the
connection state changing to VALID and waits for additional traffic - This
was very frustrating.) *****

Server Certificate common name:  "optional," but is it really (see above),
so I entered the TLS certificate's CN/SAN explicitly here

Enable EAP:  NOT SELECTED
Disconnect on Idle:  NEVER
Dead peer detection rate:  HIGH
Disable redirects:  NOT SELECTED
Disable Mobility (MOBIKE):  SELECTED
Use IP4/IP6 Subnet attributes:  SELECTED
Enable PFS:  NOT SELECTED
Enable Cert Revoke check:  NOT SELECTED


For both IKE SA and child SA parameters, I used:
AES-256
SHA2-384
DH Group 20
***** I ONLY SELECTED THESE SETTINGS HERE *****
***** When I tried to set arguments for this in iked.conf, the connection
would not work, so I did not set ANY specifics for the connection in
iked.conf *****

Proxy Server URL:  None

--------------------

Now, in my situation I also added information for DNS servers and a VPN on
demand setup.

Years ago, the DNS settings had to be done by hand to the xml file, but now
they are included in AC2.  I need this because the iOS client needs to
direct any DNS queries for my personal domain to internal DNS servers over
the tunnel.  Without setting the DNS in the profile, a VPN connection comes
up, but, unless everything on the iOS device is set with IP address, the
internal FQDN's will not resolve using public DNS servers.

So, in my case, in AC2, I added:

DNS Server Addresses:  internal IP's of my DNS servers
Domain Name:  mypersonaldn.tld
DNS Search Domains:  mypersonaldn.tld
DNS Supplemental Match Domains:  mypersonaldn.tld
Include Supplemental Domains...:  SELECTED

These settings direct iOS to send DNS queries for my personal domain through
the tunnel to my internal DNS servers for resolution.


In my case, the VPN is only used for traffic to my internal services, and
all other traffic on the iOS device is routed directly by it to whatever
gateway the device is connected to at the time.


Finally, I wanted to VPN connection to come up automatically when trying to
check (for example) email (the VPN is not "always on").

So, this requires a direct editing of the .mobileconfig xml file.

In my case, I added "OnDemand" settings to the "IKEv2" dictionary.
The Apple Reference describes the options for this.

For my situation, I added the following (I don't necessarily remember all
the reasons of exactly why I did it like this):

<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
        <dict>
                <key>Action</key>
                <string>Disconnect</string>
                <key>SSIDMatch</key>
                <array>
                        <string>PersonalSSID1</string>
                        <string>PersonalSSID2</string>
                </array>
        </dict>
        <dict>
                <key>Action</key>
                <string>EvaluateConnection</string>
                <key>ActionParameters</key>
                <array>
                        <dict>
<key>DomainAction</key>
<string>ConnectIfNeeded</string>
<key>Domains</key>
<array>
        <string> mypersonaldn.tld</string>
        <string>*. mypersonaldn.tld</string>
        <string>*.sub. mypersonaldn.tld</string>
</array>
<key>RequiredDNSServers</key>
<array>
        <string>aaa.bbb.ccc.dd1</string>
        <string>aaa.bbb.ccc.dd2</string>
</array>
                        </dict>
                </array>
        </dict>
        <dict>
                <key>Action</key>
                <string>Connect</string>
        </dict>
</array>


This addition keeps the VPN from starting when I am at home and connected
directly to an AP with a specific SSID.  But, when not connected to that AP,
any time a request is made for a location in my domain, the VPN comes up
automatically.


And that's it.
I now have iOS devices running the current iOS (14.whatever) that will
automatically connect to the -current OpenBSD iked daemon and bring up a VPN
to my home network whenever I decide to check email (or other things).

I also backdated my CA and other certs, so I am not limited by Apple's
certificate time constraints (in my situation, I see no problem with certs
that are valid for more than 3 years - after all, if a family member looses
a phone, I just delete that entry from iked.conf, and who cares how long the
certificate is valid, I am more unhappy about the lost phone).


I know this has been a long email.
I hope that this helps someone.
If there is something that needs to be clarified or explained better, please
let me know, and I will try to explain better.

Ted


Reply | Threaded
Open this post in threaded view
|

Re: How I got iked in -current to work with iOS

David Anthony
Ted,

Thank you for sending this - I’m sure it will be useful to someone, and now it’s “archived” for those who go looking for help in the future.

-David

> On Apr 2, 2021, at 3:41 PM, Theodore Wynnychenko <[hidden email]> wrote:
>
> Hi
> I had some time today, and decided to send this now.
>
> This is how I got OpenBSD's iked daemon (version in current about 3/28/2021)
> to work with Apple's iOS (iphone/ipad's) version (about) 14.4.2.
>
> Some prelude:
>
> So, I have no real reason to do this, other than that I want to.
> I think of it as a learning exercise, so my knowledge is limited in many
> ways.  I got this to work for my specific use case.
>
> Specially, I only have a few devices that I want/need to have access to my
> home's VPN.  I do this to have a secure gateway for access to my
> email/calendar/files/etc when not at home (yes, I host my own services - I
> know that Apple and Google and other respect my privacy, etc., but ...).
>
> I have NOT tried to set this up as a VPN to route all traffic from
> associated devices (I don't have the a connection with the bandwidth
> necessary to do so).
>
> Because I am only "managing" a handful of devices, I did all of this
> manually.
>
>
> Limitations/Requirements:
>
> Apple's iOS:
>
> Recently, Apple has put several restrictions on the certificates iOS devices
> will accept for ikev2 connections.  These are "disclosed" at
> https://support.apple.com/en-us/HT211025 and
> https://support.apple.com/en-us/HT210176.
>
> Specifically, certificates must:
> - CA and TLS certs using RSA must use key => 2048
> - CA and TLS certs must use SHA-2
> - TLS certs must have a SubjectAlternativeName with the DNS name of the
> server; a CommonName only is not enough
>
> For certificates issued after 7/1/2019:
> - ExtendedKeyUsage for TLS server and TLS client must be included
> - TLS certs can only be valid for 825 days or less
>
> For certificates issued by the Root CA's preinstalled in iOS, after
> 9/1/2020:
> - TLS certs can only be valid for 398 days or less
>
>
>
> OpenBSD's iked:
>
> OpenBSD ikev2 also has some specific requirements for certificate
> authentication.
>
> iked requires specific key/authentication combinations:
> - rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
> - ecdsa256 only supports P-256 with SHA2-256
> - ecdsa382 only supports P-384 with SHA2-384
> - ecdsa521 only supports P-521 with SHA2-512
> - rsa suppors RSA but only with SHA1
>
>
> Other/General:
>
> In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
> that are more generally accepted, and will likely continue to be generally
> accepted.  This appears to be based on NIST's inclusion of them in their
> "Suite B Cryptography" information.  P-521 was not included in "Suite B,"
> and it seems some things have not included support for it.
>
> So, I concluded, to be safe (and since it seems the computational/security
> cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
> above, to use P-384 with SHA2-384.
>
>
> My setup:
>
> Certificates:
>
> In order to do this, I used openssl commands directly.  I did not use ikectl
> to create certs or the CA.
>
> Before I go into details, I wanted to have certs that would last longer than
> the Apple limit.  Therefore, I needed to have a CA certificate, and TLS
> certs, that had a "Not Before" date before 7/1/2019.
>
> In order to do this, when I created my CA certificate, I changed the
> time/date on the system using "date 201901010000" before creating the CA,
> and then reset the date when I was done.
>
> Creating back-dated TLS certs is a bit more direct, all that is necessary is
> to add "-startdate 20190102000000Z" to the openssl ca command when signing
> the TLS certificate.
>
> Obviously, you need to have complete control of the CA (and not care that
> you are doing this) to accomplish this and get certificates with a longer
> time horizon for iOS.
>
> So, first I created a CA using ECDSA384:
>
> I created/edited the openssl.cnf file to have the appropriate
> additions/defaults I need for these certificates.  I will not cover
> everything, but I think these are the basic requirements (I have edited out
> many things in the actual file I used, but I THINK what is left is all that
> may be really needed, but my openssl knowledge is not absolute, and I may
> have errors that I don't realize):
>
> (NOTE:  When I was trying to get this to work, I began to believe that the
> current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not use
> them.  I now am not sure if "-"'s will work or not.]
>
> General defaults for generating the signing request (csr), openssl.cnf:
>
> default_bits        = 4096
> default_keyfile    = key.pem    
> default_md        = sha384
> string_mask        = utf8only
> distinguished_name    = req_distinguished_name
> attributes        = req_attributes
>
> The distinguished name/attributes are basically from the default cnf file.
>
> For the CA cert, openssl.cnf:
>
> basicConstraints        = CA:TRUE
> subjectKeyIdentifier    = hash
> authorityKeyIdentifier    = keyid:always,issuer:always
> issuerAltName            = issuer:copy
>
> For the TLS certs, when creating the signing request, openssl.cnf:
>
> basicConstraints        = CA:FALSE
> subjectKeyIdentifier    = hash
> authorityKeyIdentifier    = keyid:always,issuer:always
> subjectAltName            = email:move
>
> For the TLS certs, when signing with CA, openssl.cnf:
>
> default_days        = 390 # Most restrictive days for iOS
> default_md        = sha384
> preserve            = no
> email_in_dn        = no
> policy            = policy_match
> copy_extensions    = copy
> extendedKeyUsage    = serverAuth,clientAuth
> subjectAltName        = DNS:same.as.CN,email:[hidden email]
>
>
> In the steps that follow, the openssl.cnf file will need to be adjusted to
> match each certificate (both CA and TLS) as they are created.
>
> Create a CA key - I did this in two steps here, later only one:
>
> openssl ecparam -name secp384r1 -out secp384r1.param
>
> openssl ecparam -in secp384r1.param -genkey -out ca.ecdsa.key.nopass
>
> I wanted a password for the CA key, so,
>
> openssl ec -aes256 -in ca.ecdsa.key.clear -out ca.ecdsa.key.pem
>
> and then deleted the unencrypted key.
>
> Then, create the CA self-signed certificate:
>
> openssl req -new -x509 -key ca.ecdsa.key.pem -out cacert.pem -days ###
> -config openssl.cnf
>
> Now, there is a CA certificate and key with ECDSA384 and SHA2-384.
>
> Create the TLS server cert and key (only one step this time):
>
> openssl ecparam -genkey -name secp384r1 -out server.key
>
> Make the csr:
>
> openssl req -nodes -new -key ikev2.key -out server.csr -config openssl.cnf
>
> Sign the csr with the CA:
>
> openssl ca -in server.csr -out server.pem -config openssl.cnf
>
>
> Now, create a client cert the same way, but one extra step.
> First, create the key, create the CSR, and sign it to get the certificate.
>
> But, this has to be bundled in to a .p12 file for import to iOS:
>
> openssl pkcs12 -export -in client.pem -inkey client.key -CAfile cacert.pem
> -out client.p12
>
>
> Now, there is a cacert.pem (the CA certificate), a server.pem and server.key
> (the iked daemon's certificates), and a .p12 with the iOS client's
> certificate and key, and the ca certificate (even though I also import the
> cacert directly into iOS as a der file).
>
> Move the cacert.pem, server.pem, and server.key into the appropriate places
> for iked to find them.
>
>
>
> Setup IKED:
>
> If I recall, the PF setup I use just basically follows the guidance in the
> man page (I did this years ago).
>
> In my case, it looks like this:
>
> pass in  on $ext_if proto udp from any to $ext.ip port { isakmp, ipsec-nat-t
> }
> pass out on $ext_if proto udp from $ext.ip to any port { isakmp, ipsec-nat-t
> }
> pass in  on $ext_if proto udp from any to $local_net port { isakmp,
> ipsec-nat-t }
> pass out on $ext_if proto udp from $local_net to any port { isakmp,
> ipsec-nat-t }
>
> pass in  on $ext_if proto esp from any to $ext.ip
> pass out on $ext_if proto esp from $ext.ip to any
>
> pass in  on enc0 proto ipencap from any to $ext.ip keep state (if-bound)
> pass out on enc0 proto ipencap from $ext.ip to any keep state (if-bound)
>
> pass in  on enc0 from <ip_ assigned_by_iked> to any keep state (if-bound)
> pass out on enc0 from any to < ip_ assigned_by_iked > keep state (if-bound)
>
>
> I don't use NAT, since I only have a handful of devices, and each gets
> assigned a unique IP address by iked.
>
>
> Each device has its own specific entry in iked, and they look like this:
>
> ikev2 "client_1" passive esp \
>        from $local_net to $vpn_net \
>        local $local_gw peer any \
>        srcid $server_id dstid $client_id \
>        ikelifetime 30m lifetime 30m \
>        ecdsa384 \
>        config address aaa.bbb.ccc.ddd \
>        config netmask 255.255.255.0 \
>        config name-server aaa.bbb.ccc.111 \
>        config name-server aaa.bbb.ccc.222
>
>
> local_net = my internal network block
> vpn_net = network block assigned by iked to clients
> local_gw = FQDN of local endpoint
> server_id = CN/SAN of server as listed in certificate created
> client_id = CN/SAN of client as listed in certificate created
>
> I use iked to give each client a specific and unique IP address, and they
> all fall into the "vpn_net" netblock.
>
> I also "config" DNS servers.  But, I don't think iOS accepts these (as I
> will get to later), but I never bothered removing them to see if it would
> still work.
>
> So, each client has a policy in iked that matches the CN/SAN in its
> certificate, and iked also uses the CN/SAN of the server as the srcid for
> the policy.
>
>
> Finally, setting up the iOS client:
>
> In order to do this I use profiles that get imported in the iOS device.
>
> The profiles are generated by Apple Configurator 2 (which requires a Mac),
> but then also edited them directly (I will explain why later).
>
> I guess you don't really need the Apple software, as all AC2 does is
> generate an XML file.  All the parameters in AC2 (and others that are not
> available in AC2) are published by Apple in the "Configuration Profile
> Reference."  So, I guess this could be created by hand, but I choose not to.
>
> (I am not looking at the AC2 pages as I type this, so if I make a slight
> misstatement, sorry.)
>
> To create the profile, there are three sections to complete.
>
> First, I filled out the mandatory General tab.
>
> In the Certificates tab, I added the cacert.der (I converted the .pem to a
> .der for Apple, but I think it would accept the .pem if you change the file
> extension to .crt - maybe?) to the profile.
>
> I then added the client.p12 to the profile, also entering the password given
> to the .p12 when creating it.
>
> Finally, in the VPN tab, I set up the ikev2 parameters.
>
> Specially:
>
> Connection Type: IKEv2
> Server:  FQDN of my server
> Remote Identifier:  the CN/SAN from the server certificate
> Local Identifier:  the CN/SAN from the client certificate
> Machine Authentication:  Certificate
> Identity Certificate:  choose the certificate you added
> Certificate type:  ECDSA384
> Server certificate issuer common name:  CA certificate CN
>
> ***** THIS IS REQUIRED *****
> ***** EVEN THOUGH AC2 LISTS THIS FIELD AS ONLY REQUIRED FOR EAP, THE
> REFERENCE GUIDE SPECIFICALLY STATES THAT IT IS REQUIRED WHEN A CERTIFICATE
> TYPE IS SELECTED (This was the last thing I changed before getting it to
> work - without this set, iOS gives a cryptic "User authentication failed"
> error and will not connect, while AT THE SAME TIME, IKED shows the
> connection state changing to VALID and waits for additional traffic - This
> was very frustrating.) *****
>
> Server Certificate common name:  "optional," but is it really (see above),
> so I entered the TLS certificate's CN/SAN explicitly here
>
> Enable EAP:  NOT SELECTED
> Disconnect on Idle:  NEVER
> Dead peer detection rate:  HIGH
> Disable redirects:  NOT SELECTED
> Disable Mobility (MOBIKE):  SELECTED
> Use IP4/IP6 Subnet attributes:  SELECTED
> Enable PFS:  NOT SELECTED
> Enable Cert Revoke check:  NOT SELECTED
>
>
> For both IKE SA and child SA parameters, I used:
> AES-256
> SHA2-384
> DH Group 20
> ***** I ONLY SELECTED THESE SETTINGS HERE *****
> ***** When I tried to set arguments for this in iked.conf, the connection
> would not work, so I did not set ANY specifics for the connection in
> iked.conf *****
>
> Proxy Server URL:  None
>
> --------------------
>
> Now, in my situation I also added information for DNS servers and a VPN on
> demand setup.
>
> Years ago, the DNS settings had to be done by hand to the xml file, but now
> they are included in AC2.  I need this because the iOS client needs to
> direct any DNS queries for my personal domain to internal DNS servers over
> the tunnel.  Without setting the DNS in the profile, a VPN connection comes
> up, but, unless everything on the iOS device is set with IP address, the
> internal FQDN's will not resolve using public DNS servers.
>
> So, in my case, in AC2, I added:
>
> DNS Server Addresses:  internal IP's of my DNS servers
> Domain Name:  mypersonaldn.tld
> DNS Search Domains:  mypersonaldn.tld
> DNS Supplemental Match Domains:  mypersonaldn.tld
> Include Supplemental Domains...:  SELECTED
>
> These settings direct iOS to send DNS queries for my personal domain through
> the tunnel to my internal DNS servers for resolution.
>
>
> In my case, the VPN is only used for traffic to my internal services, and
> all other traffic on the iOS device is routed directly by it to whatever
> gateway the device is connected to at the time.
>
>
> Finally, I wanted to VPN connection to come up automatically when trying to
> check (for example) email (the VPN is not "always on").
>
> So, this requires a direct editing of the .mobileconfig xml file.
>
> In my case, I added "OnDemand" settings to the "IKEv2" dictionary.
> The Apple Reference describes the options for this.
>
> For my situation, I added the following (I don't necessarily remember all
> the reasons of exactly why I did it like this):
>
> <key>OnDemandEnabled</key>
> <integer>1</integer>
> <key>OnDemandRules</key>
> <array>
>    <dict>
>        <key>Action</key>
>        <string>Disconnect</string>
>        <key>SSIDMatch</key>
>        <array>
>            <string>PersonalSSID1</string>
>            <string>PersonalSSID2</string>
>        </array>
>    </dict>
>    <dict>
>        <key>Action</key>
>        <string>EvaluateConnection</string>
>        <key>ActionParameters</key>
>        <array>
>            <dict>
> <key>DomainAction</key>
> <string>ConnectIfNeeded</string>
> <key>Domains</key>
> <array>
>    <string> mypersonaldn.tld</string>
>    <string>*. mypersonaldn.tld</string>
>    <string>*.sub. mypersonaldn.tld</string>
> </array>
> <key>RequiredDNSServers</key>
> <array>
>    <string>aaa.bbb.ccc.dd1</string>
>    <string>aaa.bbb.ccc.dd2</string>
> </array>
>            </dict>
>        </array>
>    </dict>
>    <dict>
>        <key>Action</key>
>        <string>Connect</string>
>    </dict>
> </array>
>
>
> This addition keeps the VPN from starting when I am at home and connected
> directly to an AP with a specific SSID.  But, when not connected to that AP,
> any time a request is made for a location in my domain, the VPN comes up
> automatically.
>
>
> And that's it.
> I now have iOS devices running the current iOS (14.whatever) that will
> automatically connect to the -current OpenBSD iked daemon and bring up a VPN
> to my home network whenever I decide to check email (or other things).
>
> I also backdated my CA and other certs, so I am not limited by Apple's
> certificate time constraints (in my situation, I see no problem with certs
> that are valid for more than 3 years - after all, if a family member looses
> a phone, I just delete that entry from iked.conf, and who cares how long the
> certificate is valid, I am more unhappy about the lost phone).
>
>
> I know this has been a long email.
> I hope that this helps someone.
> If there is something that needs to be clarified or explained better, please
> let me know, and I will try to explain better.
>
> Ted
>
>

Reply | Threaded
Open this post in threaded view
|

Re: How I got iked in -current to work with iOS

Theodore Wynnychenko-2
In reply to this post by Theodore Wynnychenko-2
Hello - I have added a small bit of additional information at the end.

-----Original Message-----
From: Theodore Wynnychenko [mailto:[hidden email]]
Sent: Friday, April 02, 2021 1:46 PM
To: [hidden email]
Subject: How I got iked in -current to work with iOS

Hi
I had some time today, and decided to send this now.

This is how I got OpenBSD's iked daemon (version in current about
3/28/2021) to work with Apple's iOS (iphone/ipad's) version (about)
14.4.2.

Some prelude:

So, I have no real reason to do this, other than that I want to.
I think of it as a learning exercise, so my knowledge is limited in many
ways.  I got this to work for my specific use case.

Specially, I only have a few devices that I want/need to have access to my
home's VPN.  I do this to have a secure gateway for access to my
email/calendar/files/etc when not at home (yes, I host my own services - I
know that Apple and Google and other respect my privacy, etc., but ...).

I have NOT tried to set this up as a VPN to route all traffic from
associated devices (I don't have the a connection with the bandwidth
necessary to do so).

Because I am only "managing" a handful of devices, I did all of this
manually.


Limitations/Requirements:

Apple's iOS:

Recently, Apple has put several restrictions on the certificates iOS
devices will accept for ikev2 connections.  These are "disclosed" at
https://support.apple.com/en-us/HT211025 and
https://support.apple.com/en-us/HT210176.

Specifically, certificates must:
- CA and TLS certs using RSA must use key => 2048
- CA and TLS certs must use SHA-2
- TLS certs must have a SubjectAlternativeName with the DNS name of the
server; a CommonName only is not enough

For certificates issued after 7/1/2019:
- ExtendedKeyUsage for TLS server and TLS client must be included
- TLS certs can only be valid for 825 days or less

For certificates issued by the Root CA's preinstalled in iOS, after
9/1/2020:
- TLS certs can only be valid for 398 days or less



OpenBSD's iked:

OpenBSD ikev2 also has some specific requirements for certificate
authentication.

iked requires specific key/authentication combinations:
- rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
- ecdsa256 only supports P-256 with SHA2-256
- ecdsa382 only supports P-384 with SHA2-384
- ecdsa521 only supports P-521 with SHA2-512
- rsa suppors RSA but only with SHA1


Other/General:

In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
that are more generally accepted, and will likely continue to be generally
accepted.  This appears to be based on NIST's inclusion of them in their
"Suite B Cryptography" information.  P-521 was not included in "Suite B,"
and it seems some things have not included support for it.

So, I concluded, to be safe (and since it seems the computational/security
cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
above, to use P-384 with SHA2-384.


My setup:

Certificates:

In order to do this, I used openssl commands directly.  I did not use
ikectl to create certs or the CA.

Before I go into details, I wanted to have certs that would last longer
than the Apple limit.  Therefore, I needed to have a CA certificate, and
TLS certs, that had a "Not Before" date before 7/1/2019.

In order to do this, when I created my CA certificate, I changed the
time/date on the system using "date 201901010000" before creating the CA,
and then reset the date when I was done.

Creating back-dated TLS certs is a bit more direct, all that is necessary
is to add "-startdate 20190102000000Z" to the openssl ca command when
signing the TLS certificate.

Obviously, you need to have complete control of the CA (and not care that
you are doing this) to accomplish this and get certificates with a longer
time horizon for iOS.

So, first I created a CA using ECDSA384:

I created/edited the openssl.cnf file to have the appropriate
additions/defaults I need for these certificates.  I will not cover
everything, but I think these are the basic requirements (I have edited
out many things in the actual file I used, but I THINK what is left is all
that may be really needed, but my openssl knowledge is not absolute, and I
may have errors that I don't realize):

(NOTE:  When I was trying to get this to work, I began to believe that the
current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not
use them.  I now am not sure if "-"'s will work or not.]

General defaults for generating the signing request (csr), openssl.cnf:

default_bits = 4096
default_keyfile = key.pem
default_md = sha384
string_mask = utf8only
distinguished_name = req_distinguished_name
attributes = req_attributes

The distinguished name/attributes are basically from the default cnf file.

For the CA cert, openssl.cnf:

basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
issuerAltName = issuer:copy

For the TLS certs, when creating the signing request, openssl.cnf:

basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
subjectAltName = email:move

For the TLS certs, when signing with CA, openssl.cnf:

default_days = 390 # Most restrictive days for iOS
default_md = sha384
preserve = no
email_in_dn = no
policy = policy_match
copy_extensions = copy
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = DNS:same.as.CN,email:[hidden email]


In the steps that follow, the openssl.cnf file will need to be adjusted to
match each certificate (both CA and TLS) as they are created.

Create a CA key - I did this in two steps here, later only one:

openssl ecparam -name secp384r1 -out secp384r1.param

openssl ecparam -in secp384r1.param -genkey -out ca.ecdsa.key.nopass

I wanted a password for the CA key, so,

openssl ec -aes256 -in ca.ecdsa.key.clear -out ca.ecdsa.key.pem

and then deleted the unencrypted key.

Then, create the CA self-signed certificate:

openssl req -new -x509 -key ca.ecdsa.key.pem -out cacert.pem -days ###
-config openssl.cnf

Now, there is a CA certificate and key with ECDSA384 and SHA2-384.

Create the TLS server cert and key (only one step this time):

openssl ecparam -genkey -name secp384r1 -out server.key

Make the csr:

openssl req -nodes -new -key ikev2.key -out server.csr -config openssl.cnf

Sign the csr with the CA:

openssl ca -in server.csr -out server.pem -config openssl.cnf


Now, create a client cert the same way, but one extra step.
First, create the key, create the CSR, and sign it to get the certificate.

But, this has to be bundled in to a .p12 file for import to iOS:

openssl pkcs12 -export -in client.pem -inkey client.key -CAfile cacert.pem
-out client.p12


Now, there is a cacert.pem (the CA certificate), a server.pem and
server.key (the iked daemon's certificates), and a .p12 with the iOS
client's certificate and key, and the ca certificate (even though I also
import the cacert directly into iOS as a der file).

Move the cacert.pem, server.pem, and server.key into the appropriate
places for iked to find them.



Setup IKED:

If I recall, the PF setup I use just basically follows the guidance in the
man page (I did this years ago).

In my case, it looks like this:

pass in  on $ext_if proto udp from any to $ext.ip port { isakmp,
ipsec-nat-t }
pass out on $ext_if proto udp from $ext.ip to any port { isakmp,
ipsec-nat-t }
pass in  on $ext_if proto udp from any to $local_net port { isakmp,
ipsec-nat-t }
pass out on $ext_if proto udp from $local_net to any port { isakmp,
ipsec-nat-t }

pass in  on $ext_if proto esp from any to $ext.ip
pass out on $ext_if proto esp from $ext.ip to any

pass in  on enc0 proto ipencap from any to $ext.ip keep state (if-bound)
pass out on enc0 proto ipencap from $ext.ip to any keep state (if-bound)

pass in  on enc0 from <ip_ assigned_by_iked> to any keep state (if-bound)
pass out on enc0 from any to < ip_ assigned_by_iked > keep state
(if-bound)


I don't use NAT, since I only have a handful of devices, and each gets
assigned a unique IP address by iked.


Each device has its own specific entry in iked, and they look like this:

ikev2 "client_1" passive esp \
        from $local_net to $vpn_net \
        local $local_gw peer any \
        srcid $server_id dstid $client_id \
        ikelifetime 30m lifetime 30m \
        ecdsa384 \
        config address aaa.bbb.ccc.ddd \
        config netmask 255.255.255.0 \
        config name-server aaa.bbb.ccc.111 \
        config name-server aaa.bbb.ccc.222


local_net = my internal network block
vpn_net = network block assigned by iked to clients
local_gw = FQDN of local endpoint
server_id = CN/SAN of server as listed in certificate created
client_id = CN/SAN of client as listed in certificate created

I use iked to give each client a specific and unique IP address, and they
all fall into the "vpn_net" netblock.

I also "config" DNS servers.  But, I don't think iOS accepts these (as I
will get to later), but I never bothered removing them to see if it would
still work.

So, each client has a policy in iked that matches the CN/SAN in its
certificate, and iked also uses the CN/SAN of the server as the srcid for
the policy.


Finally, setting up the iOS client:

In order to do this I use profiles that get imported in the iOS device.

The profiles are generated by Apple Configurator 2 (which requires a Mac),
but then also edited them directly (I will explain why later).

I guess you don't really need the Apple software, as all AC2 does is
generate an XML file.  All the parameters in AC2 (and others that are not
available in AC2) are published by Apple in the "Configuration Profile
Reference."  So, I guess this could be created by hand, but I choose not
to.

(I am not looking at the AC2 pages as I type this, so if I make a slight
misstatement, sorry.)

To create the profile, there are three sections to complete.

First, I filled out the mandatory General tab.

In the Certificates tab, I added the cacert.der (I converted the .pem to a
.der for Apple, but I think it would accept the .pem if you change the
file extension to .crt - maybe?) to the profile.

I then added the client.p12 to the profile, also entering the password
given to the .p12 when creating it.

Finally, in the VPN tab, I set up the ikev2 parameters.

Specially:

Connection Type: IKEv2
Server:  FQDN of my server
Remote Identifier:  the CN/SAN from the server certificate
Local Identifier:  the CN/SAN from the client certificate
Machine Authentication:  Certificate
Identity Certificate:  choose the certificate you added
Certificate type:  ECDSA384
Server certificate issuer common name:  CA certificate CN

***** THIS IS REQUIRED *****
***** EVEN THOUGH AC2 LISTS THIS FIELD AS ONLY REQUIRED FOR EAP, THE
REFERENCE GUIDE SPECIFICALLY STATES THAT IT IS REQUIRED WHEN A CERTIFICATE
TYPE IS SELECTED (This was the last thing I changed before getting it to
work - without this set, iOS gives a cryptic "User authentication failed"
error and will not connect, while AT THE SAME TIME, IKED shows the
connection state changing to VALID and waits for additional traffic - This
was very frustrating.) *****

Server Certificate common name:  "optional," but is it really (see above),
so I entered the TLS certificate's CN/SAN explicitly here

Enable EAP:  NOT SELECTED
Disconnect on Idle:  NEVER
Dead peer detection rate:  HIGH
Disable redirects:  NOT SELECTED
Disable Mobility (MOBIKE):  SELECTED
Use IP4/IP6 Subnet attributes:  SELECTED
Enable PFS:  NOT SELECTED
Enable Cert Revoke check:  NOT SELECTED


For both IKE SA and child SA parameters, I used:
AES-256
SHA2-384
DH Group 20
***** I ONLY SELECTED THESE SETTINGS HERE *****
***** When I tried to set arguments for this in iked.conf, the connection
would not work, so I did not set ANY specifics for the connection in
iked.conf *****

Proxy Server URL:  None

--------------------

Now, in my situation I also added information for DNS servers and a VPN on
demand setup.

Years ago, the DNS settings had to be done by hand to the xml file, but
now they are included in AC2.  I need this because the iOS client needs to
direct any DNS queries for my personal domain to internal DNS servers over
the tunnel.  Without setting the DNS in the profile, a VPN connection
comes up, but, unless everything on the iOS device is set with IP address,
the internal FQDN's will not resolve using public DNS servers.

So, in my case, in AC2, I added:

DNS Server Addresses:  internal IP's of my DNS servers
Domain Name:  mypersonaldn.tld
DNS Search Domains:  mypersonaldn.tld
DNS Supplemental Match Domains:  mypersonaldn.tld
Include Supplemental Domains...:  SELECTED

These settings direct iOS to send DNS queries for my personal domain
through the tunnel to my internal DNS servers for resolution.


In my case, the VPN is only used for traffic to my internal services, and
all other traffic on the iOS device is routed directly by it to whatever
gateway the device is connected to at the time.


Finally, I wanted to VPN connection to come up automatically when trying
to check (for example) email (the VPN is not "always on").

So, this requires a direct editing of the .mobileconfig xml file.

In my case, I added "OnDemand" settings to the "IKEv2" dictionary.
The Apple Reference describes the options for this.

For my situation, I added the following (I don't necessarily remember all
the reasons of exactly why I did it like this):

<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
        <dict>
                <key>Action</key>
                <string>Disconnect</string>
                <key>SSIDMatch</key>
                <array>
                        <string>PersonalSSID1</string>
                        <string>PersonalSSID2</string>
                </array>
        </dict>
        <dict>
                <key>Action</key>
                <string>EvaluateConnection</string>
                <key>ActionParameters</key>
                <array>
                        <dict>
<key>DomainAction</key>
<string>ConnectIfNeeded</string>
<key>Domains</key>
<array>
        <string> mypersonaldn.tld</string>
        <string>*. mypersonaldn.tld</string>
        <string>*.sub. mypersonaldn.tld</string>
</array>
<key>RequiredDNSServers</key>
<array>
        <string>aaa.bbb.ccc.dd1</string>
        <string>aaa.bbb.ccc.dd2</string>
</array>
                        </dict>
                </array>
        </dict>
        <dict>
                <key>Action</key>
                <string>Connect</string>
        </dict>
</array>


This addition keeps the VPN from starting when I am at home and connected
directly to an AP with a specific SSID.  But, when not connected to that
AP, any time a request is made for a location in my domain, the VPN comes
up automatically.


And that's it.
I now have iOS devices running the current iOS (14.whatever) that will
automatically connect to the -current OpenBSD iked daemon and bring up a
VPN to my home network whenever I decide to check email (or other things).

I also backdated my CA and other certs, so I am not limited by Apple's
certificate time constraints (in my situation, I see no problem with certs
that are valid for more than 3 years - after all, if a family member
looses a phone, I just delete that entry from iked.conf, and who cares how
long the certificate is valid, I am more unhappy about the lost phone).


I know this has been a long email.
I hope that this helps someone.
If there is something that needs to be clarified or explained better,
please let me know, and I will try to explain better.

Ted

------------------

FOLLOWUP:

I was thinking about this, and wanted to mention one other thing.

I did not include this in the original message, because I really do not
believe it is important/makes a difference.

As I was trying to get this to work, I made a number of changes to my
configurations/certificates.

Some of the things I added to my certificates were CRL and OCSP extensions.
I thought maybe Apple's iOS was looking for this information in
certificates, and that was why it was failing.

Now, I never generated a CRL for this CA, nor do I have a running OCSP
server.  I just put "placeholder" entries in the certificates.

It did not seem to matter, so I did not mention it yesterday.

But, I realized that the final certificates I created that work contain
these extensions.  I did not bother recreating certificates without these
extensions once I got it working.

I really don't think this matters to Apple's iOS, but I am wrong all the
time.

So, if the steps above don't work, consider adding this additional extension
information to the CA, TLS, and client certificates.

In my case, I have added (to my openssl.cnf file):

authorityInfoAccess = OCSP;URI:http://ocsp.mydomain.tld:2560

and

crlDistributionPoints = crldp1_section

[crldp1_section]
fullname=URI:https://crl.mydomain.tld/mydomain.ca.crl
CRLissuer=dirName:issuer_sect

[issuer_sect]
C=US
O=OrgName
CN=CAcertCN


Just wanted to mention this in case it matters.  But, I really don't think
it does.
Ted





Reply | Threaded
Open this post in threaded view
|

Re: How I got iked in -current to work with iOS

Theodore Wynnychenko-2
In reply to this post by Theodore Wynnychenko-2
Hello - I have added a small bit of additional information at the end.

-----Original Message-----
From: Theodore Wynnychenko
Sent: Friday, April 02, 2021 1:46 PM
To: [hidden email]
Subject: How I got iked in -current to work with iOS

Hi
I had some time today, and decided to send this now.

This is how I got OpenBSD's iked daemon (version in current about
3/28/2021) to work with Apple's iOS (iphone/ipad's) version (about)
14.4.2.

Some prelude:

So, I have no real reason to do this, other than that I want to.
I think of it as a learning exercise, so my knowledge is limited in many
ways.  I got this to work for my specific use case.

Specially, I only have a few devices that I want/need to have access to my
home's VPN.  I do this to have a secure gateway for access to my
email/calendar/files/etc when not at home (yes, I host my own services - I
know that Apple and Google and other respect my privacy, etc., but ...).

I have NOT tried to set this up as a VPN to route all traffic from
associated devices (I don't have the a connection with the bandwidth
necessary to do so).

Because I am only "managing" a handful of devices, I did all of this
manually.


Limitations/Requirements:

Apple's iOS:

Recently, Apple has put several restrictions on the certificates iOS
devices will accept for ikev2 connections.  These are "disclosed" at
https://support.apple.com/en-us/HT211025 and
https://support.apple.com/en-us/HT210176.

Specifically, certificates must:
- CA and TLS certs using RSA must use key => 2048
- CA and TLS certs must use SHA-2
- TLS certs must have a SubjectAlternativeName with the DNS name of the
server; a CommonName only is not enough

For certificates issued after 7/1/2019:
- ExtendedKeyUsage for TLS server and TLS client must be included
- TLS certs can only be valid for 825 days or less

For certificates issued by the Root CA's preinstalled in iOS, after
9/1/2020:
- TLS certs can only be valid for 398 days or less



OpenBSD's iked:

OpenBSD ikev2 also has some specific requirements for certificate
authentication.

iked requires specific key/authentication combinations:
- rfc7427 only supports SHA2-256 (not sure if iOS supports rfc7427)
- ecdsa256 only supports P-256 with SHA2-256
- ecdsa382 only supports P-384 with SHA2-384
- ecdsa521 only supports P-521 with SHA2-512
- rsa suppors RSA but only with SHA1


Other/General:

In terms of ECDSA certificates, it seems that P-256 and P-384 are the ones
that are more generally accepted, and will likely continue to be generally
accepted.  This appears to be based on NIST's inclusion of them in their
"Suite B Cryptography" information.  P-521 was not included in "Suite B,"
and it seems some things have not included support for it.

So, I concluded, to be safe (and since it seems the computational/security
cost/benefit of P-384 vs P-521 is narrow), and based on the requirements
above, to use P-384 with SHA2-384.


My setup:

Certificates:

In order to do this, I used openssl commands directly.  I did not use
ikectl to create certs or the CA.

Before I go into details, I wanted to have certs that would last longer
than the Apple limit.  Therefore, I needed to have a CA certificate, and
TLS certs, that had a "Not Before" date before 7/1/2019.

In order to do this, when I created my CA certificate, I changed the
time/date on the system using "date 201901010000" before creating the CA,
and then reset the date when I was done.

Creating back-dated TLS certs is a bit more direct, all that is necessary
is to add "-startdate 20190102000000Z" to the openssl ca command when
signing the TLS certificate.

Obviously, you need to have complete control of the CA (and not care that
you are doing this) to accomplish this and get certificates with a longer
time horizon for iOS.

So, first I created a CA using ECDSA384:

I created/edited the openssl.cnf file to have the appropriate
additions/defaults I need for these certificates.  I will not cover
everything, but I think these are the basic requirements (I have edited
out many things in the actual file I used, but I THINK what is left is all
that may be really needed, but my openssl knowledge is not absolute, and I
may have errors that I don't realize):

(NOTE:  When I was trying to get this to work, I began to believe that the
current iOS has a problem with "-" [hyphens] in the CN/SAN, so I did not
use them.  I now am not sure if "-"'s will work or not.]

General defaults for generating the signing request (csr), openssl.cnf:

default_bits = 4096
default_keyfile = key.pem
default_md = sha384
string_mask = utf8only
distinguished_name = req_distinguished_name
attributes = req_attributes

The distinguished name/attributes are basically from the default cnf file.

For the CA cert, openssl.cnf:

basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
issuerAltName = issuer:copy

For the TLS certs, when creating the signing request, openssl.cnf:

basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
subjectAltName = email:move

For the TLS certs, when signing with CA, openssl.cnf:

default_days = 390 # Most restrictive days for iOS
default_md = sha384
preserve = no
email_in_dn = no
policy = policy_match
copy_extensions = copy
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = DNS:same.as.CN,email:[hidden email]


In the steps that follow, the openssl.cnf file will need to be adjusted to
match each certificate (both CA and TLS) as they are created.

Create a CA key - I did this in two steps here, later only one:

openssl ecparam -name secp384r1 -out secp384r1.param

openssl ecparam -in secp384r1.param -genkey -out ca.ecdsa.key.nopass

I wanted a password for the CA key, so,

openssl ec -aes256 -in ca.ecdsa.key.clear -out ca.ecdsa.key.pem

and then deleted the unencrypted key.

Then, create the CA self-signed certificate:

openssl req -new -x509 -key ca.ecdsa.key.pem -out cacert.pem -days ###
-config openssl.cnf

Now, there is a CA certificate and key with ECDSA384 and SHA2-384.

Create the TLS server cert and key (only one step this time):

openssl ecparam -genkey -name secp384r1 -out server.key

Make the csr:

openssl req -nodes -new -key ikev2.key -out server.csr -config openssl.cnf

Sign the csr with the CA:

openssl ca -in server.csr -out server.pem -config openssl.cnf


Now, create a client cert the same way, but one extra step.
First, create the key, create the CSR, and sign it to get the certificate.

But, this has to be bundled in to a .p12 file for import to iOS:

openssl pkcs12 -export -in client.pem -inkey client.key -CAfile cacert.pem
-out client.p12


Now, there is a cacert.pem (the CA certificate), a server.pem and
server.key (the iked daemon's certificates), and a .p12 with the iOS
client's certificate and key, and the ca certificate (even though I also
import the cacert directly into iOS as a der file).

Move the cacert.pem, server.pem, and server.key into the appropriate
places for iked to find them.



Setup IKED:

If I recall, the PF setup I use just basically follows the guidance in the
man page (I did this years ago).

In my case, it looks like this:

pass in  on $ext_if proto udp from any to $ext.ip port { isakmp,
ipsec-nat-t }
pass out on $ext_if proto udp from $ext.ip to any port { isakmp,
ipsec-nat-t }
pass in  on $ext_if proto udp from any to $local_net port { isakmp,
ipsec-nat-t }
pass out on $ext_if proto udp from $local_net to any port { isakmp,
ipsec-nat-t }

pass in  on $ext_if proto esp from any to $ext.ip
pass out on $ext_if proto esp from $ext.ip to any

pass in  on enc0 proto ipencap from any to $ext.ip keep state (if-bound)
pass out on enc0 proto ipencap from $ext.ip to any keep state (if-bound)

pass in  on enc0 from <ip_ assigned_by_iked> to any keep state (if-bound)
pass out on enc0 from any to < ip_ assigned_by_iked > keep state
(if-bound)


I don't use NAT, since I only have a handful of devices, and each gets
assigned a unique IP address by iked.


Each device has its own specific entry in iked, and they look like this:

ikev2 "client_1" passive esp \
        from $local_net to $vpn_net \
        local $local_gw peer any \
        srcid $server_id dstid $client_id \
        ikelifetime 30m lifetime 30m \
        ecdsa384 \
        config address aaa.bbb.ccc.ddd \
        config netmask 255.255.255.0 \
        config name-server aaa.bbb.ccc.111 \
        config name-server aaa.bbb.ccc.222


local_net = my internal network block
vpn_net = network block assigned by iked to clients
local_gw = FQDN of local endpoint
server_id = CN/SAN of server as listed in certificate created
client_id = CN/SAN of client as listed in certificate created

I use iked to give each client a specific and unique IP address, and they
all fall into the "vpn_net" netblock.

I also "config" DNS servers.  But, I don't think iOS accepts these (as I
will get to later), but I never bothered removing them to see if it would
still work.

So, each client has a policy in iked that matches the CN/SAN in its
certificate, and iked also uses the CN/SAN of the server as the srcid for
the policy.


Finally, setting up the iOS client:

In order to do this I use profiles that get imported in the iOS device.

The profiles are generated by Apple Configurator 2 (which requires a Mac),
but then also edited them directly (I will explain why later).

I guess you don't really need the Apple software, as all AC2 does is
generate an XML file.  All the parameters in AC2 (and others that are not
available in AC2) are published by Apple in the "Configuration Profile
Reference."  So, I guess this could be created by hand, but I choose not
to.

(I am not looking at the AC2 pages as I type this, so if I make a slight
misstatement, sorry.)

To create the profile, there are three sections to complete.

First, I filled out the mandatory General tab.

In the Certificates tab, I added the cacert.der (I converted the .pem to a
.der for Apple, but I think it would accept the .pem if you change the
file extension to .crt - maybe?) to the profile.

I then added the client.p12 to the profile, also entering the password
given to the .p12 when creating it.

Finally, in the VPN tab, I set up the ikev2 parameters.

Specially:

Connection Type: IKEv2
Server:  FQDN of my server
Remote Identifier:  the CN/SAN from the server certificate
Local Identifier:  the CN/SAN from the client certificate
Machine Authentication:  Certificate
Identity Certificate:  choose the certificate you added
Certificate type:  ECDSA384
Server certificate issuer common name:  CA certificate CN

***** THIS IS REQUIRED *****
***** EVEN THOUGH AC2 LISTS THIS FIELD AS ONLY REQUIRED FOR EAP, THE
REFERENCE GUIDE SPECIFICALLY STATES THAT IT IS REQUIRED WHEN A CERTIFICATE
TYPE IS SELECTED (This was the last thing I changed before getting it to
work - without this set, iOS gives a cryptic "User authentication failed"
error and will not connect, while AT THE SAME TIME, IKED shows the
connection state changing to VALID and waits for additional traffic - This
was very frustrating.) *****

Server Certificate common name:  "optional," but is it really (see above),
so I entered the TLS certificate's CN/SAN explicitly here

Enable EAP:  NOT SELECTED
Disconnect on Idle:  NEVER
Dead peer detection rate:  HIGH
Disable redirects:  NOT SELECTED
Disable Mobility (MOBIKE):  SELECTED
Use IP4/IP6 Subnet attributes:  SELECTED
Enable PFS:  NOT SELECTED
Enable Cert Revoke check:  NOT SELECTED


For both IKE SA and child SA parameters, I used:
AES-256
SHA2-384
DH Group 20
***** I ONLY SELECTED THESE SETTINGS HERE *****
***** When I tried to set arguments for this in iked.conf, the connection
would not work, so I did not set ANY specifics for the connection in
iked.conf *****

Proxy Server URL:  None

--------------------

Now, in my situation I also added information for DNS servers and a VPN on
demand setup.

Years ago, the DNS settings had to be done by hand to the xml file, but
now they are included in AC2.  I need this because the iOS client needs to
direct any DNS queries for my personal domain to internal DNS servers over
the tunnel.  Without setting the DNS in the profile, a VPN connection
comes up, but, unless everything on the iOS device is set with IP address,
the internal FQDN's will not resolve using public DNS servers.

So, in my case, in AC2, I added:

DNS Server Addresses:  internal IP's of my DNS servers
Domain Name:  mypersonaldn.tld
DNS Search Domains:  mypersonaldn.tld
DNS Supplemental Match Domains:  mypersonaldn.tld
Include Supplemental Domains...:  SELECTED

These settings direct iOS to send DNS queries for my personal domain
through the tunnel to my internal DNS servers for resolution.


In my case, the VPN is only used for traffic to my internal services, and
all other traffic on the iOS device is routed directly by it to whatever
gateway the device is connected to at the time.


Finally, I wanted to VPN connection to come up automatically when trying
to check (for example) email (the VPN is not "always on").

So, this requires a direct editing of the .mobileconfig xml file.

In my case, I added "OnDemand" settings to the "IKEv2" dictionary.
The Apple Reference describes the options for this.

For my situation, I added the following (I don't necessarily remember all
the reasons of exactly why I did it like this):

<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
        <dict>
                <key>Action</key>
                <string>Disconnect</string>
                <key>SSIDMatch</key>
                <array>
                        <string>PersonalSSID1</string>
                        <string>PersonalSSID2</string>
                </array>
        </dict>
        <dict>
                <key>Action</key>
                <string>EvaluateConnection</string>
                <key>ActionParameters</key>
                <array>
                        <dict>
<key>DomainAction</key>
<string>ConnectIfNeeded</string>
<key>Domains</key>
<array>
        <string> mypersonaldn.tld</string>
        <string>*. mypersonaldn.tld</string>
        <string>*.sub. mypersonaldn.tld</string>
</array>
<key>RequiredDNSServers</key>
<array>
        <string>aaa.bbb.ccc.dd1</string>
        <string>aaa.bbb.ccc.dd2</string>
</array>
                        </dict>
                </array>
        </dict>
        <dict>
                <key>Action</key>
                <string>Connect</string>
        </dict>
</array>


This addition keeps the VPN from starting when I am at home and connected
directly to an AP with a specific SSID.  But, when not connected to that
AP, any time a request is made for a location in my domain, the VPN comes
up automatically.


And that's it.
I now have iOS devices running the current iOS (14.whatever) that will
automatically connect to the -current OpenBSD iked daemon and bring up a
VPN to my home network whenever I decide to check email (or other things).

I also backdated my CA and other certs, so I am not limited by Apple's
certificate time constraints (in my situation, I see no problem with certs
that are valid for more than 3 years - after all, if a family member
looses a phone, I just delete that entry from iked.conf, and who cares how
long the certificate is valid, I am more unhappy about the lost phone).


I know this has been a long email.
I hope that this helps someone.
If there is something that needs to be clarified or explained better,
please let me know, and I will try to explain better.

Ted

------------------

FOLLOWUP:

I was thinking about this, and wanted to mention one other thing.

I did not include this in the original message, because I really do not
believe it is important/makes a difference.

As I was trying to get this to work, I made a number of changes to my
configurations/certificates.

Some of the things I added to my certificates were CRL and OCSP
extensions.  I thought maybe Apple's iOS was looking for this information
in certificates, and that was why it was failing.

Now, I never generated a CRL for this CA, nor do I have a running OCSP
server.  I just put "placeholder" entries in the certificates.

It did not seem to matter, so I did not mention it yesterday.

But, I realized that the final certificates I created that work contain
these extensions.  I did not bother recreating certificates without these
extensions once I got it working.

I really don't think this matters to Apple's iOS, but I am wrong all the
time.

So, if the steps above don't work, consider adding this additional
extension information to the CA, TLS, and client certificates.

In my case, I have added (to my openssl.cnf file):

authorityInfoAccess = OCSP;URI:http://ocsp.mydomain.tld:2560

and

crlDistributionPoints = crldp1_section

[crldp1_section]
fullname=URI:https://crl.mydomain.tld/mydomain.ca.crl
CRLissuer=dirName:issuer_sect

[issuer_sect]
C=US
O=OrgName
CN=CAcertCN


Just wanted to mention this in case it matters.  But, I really don't think
it does.
Ted