On 01/03/2023 03:37, Luke Kenneth Casson Leighton wrote:
>
>
> On Tuesday, February 28, 2023, <jbranso@dismail.de
> <mailto:jbranso@dismail.de>> wrote:
> > Hello you fabulous developers!
> >
> > My friend has a spare Talos II motherboard that is currently sitting
> in his house
> > in Indiana USA collecting dust.
> >
> > https://www.raptorcs.com/TALOSII/ <https://www.raptorcs.com/TALOSII/>
> >
> > I have convinced him to donate/sell it to an open source project or
> developer.
> >
> > I reached out to Richard Stallman, and he agreed to take the board.
> I am certain that the
> > FSF would put it to good use. My friend and I have not yet decided,
> to whom we will give
> > the motherboard. Is it possible that I could give it to someone or
> project, such that all
> > parties here would benefit?
>
> i am reasonably certain that Toshaan Bharvani would be
> prepared to do that although he would need to speak for
> himself.
Yes, please, I am interested.
I would use it for PowerEL, LibreBMC and LibreSOC.
All open source projects.
Is this just a board or also a CPU?
>
> the other option would be to donate it to the University of
> Oregon who already have POWER9 systems that are accessible
> to FOSS projects via the "OpenPOWER Hub". cc'ing Sameer
> as well.
>
> (in case that wasn't clear: FOSS projects can *already*, right
> now, apply for access to POWER9 systems, do i have that right,
> Sameer?)
>
> > Is there any project or developer here that would be willing to take
> this motherboard and create
> > virtual machines that other projects could have access to?
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Joshua Branson
> > FOSS enthusiast
> > https://gnucode.me <https://gnucode.me>
> >
> >
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> <https://www.crowdsupply.com/eoma68>
>
--
--
Toshaan Bharvani
+32-(0)476-66.70.55
toshaan@vantosh.com
@toshywoshy
----------------------------------------
__ __ _____ _
\ \ / /_ _ _ _|_ _|__ ___| |__
\ \ / / _` | '_ \| |/ _ \/ __| '_ \
\ V / (_| | | | | | (_) \__ \ | | |
\_/ \__,_|_| |_|_|\___/|___/_| |_|
http://www.vantosh.com
----------------------------------------
--
Wednesday, March 01, 2023
Re: Authentication in OpenIKED
On 2023-03-01, J Doe <general@nativemethods.com> wrote:
> Hello,
>
> I have a question regarding authentication options in OpenIKED on
> OpenBSD 7.2
>
> On my test lab I have one OpenBSD 7.2 machine with OpenIKED configured
> to use PSK and a macOS 13.2.1 client that can connect to it.
>
> I read in: man iked.conf that PSK should not be used, so I am now
I don't see that in the iked.conf manual. There is some reference to not
using psk in /etc/examples/iked.conf but it's not clear whether that's
because of the need to share a single psk with all endpoints connecting
via the same iked.conf configuration line (certainly a problem when
you have multiple users from unknown IPs but perhaps not if used for
separately-configured lan-to-lan tunnels with strong randomly generated
psks) or whether it's something else.
> investigating EAP with MSCHAP-V2 and X.509 certificate authentication,
> but I am confused as to which is more secure.
>
> It seems to me that if I use EAP with MSCHAP-V2, I need a certificate on
> the OpenBSD machine, but I can connect from the macOS client with a user
> name and password, whereas X.509 authentication requires an X.509
> certificate on *BOTH* client and server - is that correct ?
Yes.
> If it is, is the reason that X.509 authentication is more secure because
> of the two certificates required, whereas authentication with EAP with
> MSCHAP-V2 is less secure because only one certificate is required ?
One problem is that MSCHAPv2 requires that the password is stored
in cleartext rather than some kind of hash, so someone with access
to the server config is able to connect (as any user), whereas with
certificates this can't be done.
Another is that it's a password which must often be typed by a user,
so in that case there's some disincentive to having a more secure
but hard to type password.
(There are other long documented problems with MSCHAPv2 but my
understanding is that those are not so important when used with in
conjunction with protocols like IKEv2 and PEAP where the auth is done
over a channel which is already secure - however that does require that
the initiator actually checks the certificate sent by the responder
otherwise MITM is a problem - and in most implementations it's all too
easy to disable checking this i.e. on the client side).
--
Please keep replies on the mailing list.
> Hello,
>
> I have a question regarding authentication options in OpenIKED on
> OpenBSD 7.2
>
> On my test lab I have one OpenBSD 7.2 machine with OpenIKED configured
> to use PSK and a macOS 13.2.1 client that can connect to it.
>
> I read in: man iked.conf that PSK should not be used, so I am now
I don't see that in the iked.conf manual. There is some reference to not
using psk in /etc/examples/iked.conf but it's not clear whether that's
because of the need to share a single psk with all endpoints connecting
via the same iked.conf configuration line (certainly a problem when
you have multiple users from unknown IPs but perhaps not if used for
separately-configured lan-to-lan tunnels with strong randomly generated
psks) or whether it's something else.
> investigating EAP with MSCHAP-V2 and X.509 certificate authentication,
> but I am confused as to which is more secure.
>
> It seems to me that if I use EAP with MSCHAP-V2, I need a certificate on
> the OpenBSD machine, but I can connect from the macOS client with a user
> name and password, whereas X.509 authentication requires an X.509
> certificate on *BOTH* client and server - is that correct ?
Yes.
> If it is, is the reason that X.509 authentication is more secure because
> of the two certificates required, whereas authentication with EAP with
> MSCHAP-V2 is less secure because only one certificate is required ?
One problem is that MSCHAPv2 requires that the password is stored
in cleartext rather than some kind of hash, so someone with access
to the server config is able to connect (as any user), whereas with
certificates this can't be done.
Another is that it's a password which must often be typed by a user,
so in that case there's some disincentive to having a more secure
but hard to type password.
(There are other long documented problems with MSCHAPv2 but my
understanding is that those are not so important when used with in
conjunction with protocols like IKEv2 and PEAP where the auth is done
over a channel which is already secure - however that does require that
the initiator actually checks the certificate sent by the responder
otherwise MITM is a problem - and in most implementations it's all too
easy to disable checking this i.e. on the client side).
--
Please keep replies on the mailing list.
Subscribe to:
Posts (Atom)