On 2024-07-25 03:11, Crystal Kolipe wrote:
> On Wed, Jul 24, 2024 at 06:20:26PM -0400, J Doe wrote:
>> My hypothesis is that iked does not name an identity because this is
>> certificate based authentication vs. MSCHAPv2 for EAP authentication
>> which would provide an identity (ie: a username).
>>
>> Is that correct ?
>
> No.
>
> The identity that would be printed is the srcid of the peer. By default this
> would be it's hostname, and should be present in the SAN field of any
> certificate used for iked.
>
> You can see that error message displayed both with and without a named ID when
> using certificate authentication, depending on the cause of the error.
>
> It will also display without an ID even if one if known, if the printing code
> in iked fails some internal consistency checks, (which is unlikely but
> possible).
Hi Crystal,
Thank you for your reply.
I had a chance to experiment a bit with this, this past weekend. The
client OS was mac OS Sonoma (macOS 14.5).
Firstly, I configured my Mac to connect to my OpenBSD server with a
local ID of nothing (empty string), using shared secret and
username/password authentication.
As my OpenBSD server is configured for x.509 certificate authentication,
these two logon attempts were rejected and the OpenBSD server logs noted
what I mentioned in my original message: "authentication failed for"
without listing an identity.
Secondly, I then repeated this but specified an arbitrary identity for
the local ID (ie: whatever.com). This also produced the same log
results: "authentication failed for" without listing an identity.
Lastly, I repeated this with the local ID on the Mac set to the same
value as the: dstid in my: iked.conf file:
kev2 "VPN" passive ipcomp tunnel esp \
from any to dynamic \
local egress peer any \
srcid server.home.arpa \
dstid client.home.arpa \
config address 10.0.5.0/24 \
tag "ROADW"
... so the local ID on the Mac was: "client.home.arpa". I then
attempted to logon with a shared secret and username/password and noted
the following in my logs: "authentication failed for FQDN/client.home.arpa"
This replicated what you said in your reply:
"No. The identity that would be printed is the srcid of the peer"
... which clears up my original question - thank you!
As a result with continuing to experiment with my configuration, I ran
into a new issue. I followed the instructions in the OpenBSD FAQ[0] for
an X.509 configuration - in particular the following (with hostnames for
my server and Mac):
server1# ikectl ca vpn certificate client1.domain create
server1# cp /etc/ssl/vpn/client1.domain.crt /etc/iked/certs/
server1# ikectl ca vpn certificate client1.domain export
server1# tar -C /tmp -xzf client1.domain.tgz *pfx
server1# cp /tmp/export/client1.domain.pfx \
/var/www/htdocs/client1.domain.pfx
...so on my OpenBSD server I have the client's X.509 certificate and the
CA certificate at: /etc/iked/certs.
I then removed the _client_ certificate from this location on the server
and attempted connecting from the Mac and it authenticated.
My new question is - shouldn't the server reject a X.509 authentication
attempt if the _client_ certificate is not on the server ? I was under
the impression that X.509 authentication with iked would be the same as
SSH - that the _client_ public key MUST be on the server (as stored in
the certificate) ?
Thanks,
- J
Links:
======
[0] https://www.openbsd.org/faq/faq17.html#authx509
No comments:
Post a Comment