Re: How I got iked in -current to work with iOS
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: misc@openbsd.org 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 20190101" 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 2019010200Z" 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
Re: How I got iked in -current to work with iOS
Hello - I have added a small bit of additional information at the end. -Original Message- From: Theodore Wynnychenko [mailto:t...@uchicago.edu] Sent: Friday, April 02, 2021 1:46 PM To: misc@openbsd.org 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 20190101" 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 2019010200Z" 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
Re: How I got iked in -current to work with iOS
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 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 20190101" 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 2019010200Z" 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. > >
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 20190101" 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 2019010200Z" 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
