Traffic protection without encryption
I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates. I'm going to speak to some infosec geeks about this tonight NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto. -- Benjamin
Good direction, but I'd drop the requirement for policing the network by actively preventing hams from using crypto. Hams are supposed to be self-policing, and we'll be engaging a losing battle, and inviting exploits. Let's just provide the tools to play nice. If people wanna run astray of rules, HamWAN as repeater operator, is not ultimately responsible. Let us know how the infonerd thing goes. :) --Bart On 2/21/2013 7:21 PM, Benjamin Krueger wrote:
I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
That *should* be how things work, but a bunch of rulings about message passing on packet networks threw that on its head. We need to take reasonable precautions to prevent encrypted traffic from moving over the network. Blocking common encrypted ports is simple and no-cost. On Thu, Feb 21, 2013 at 7:46 PM, Bart Kus <me@bartk.us> wrote:
Good direction, but I'd drop the requirement for policing the network by actively preventing hams from using crypto. Hams are supposed to be self-policing, and we'll be engaging a losing battle, and inviting exploits. Let's just provide the tools to play nice. If people wanna run astray of rules, HamWAN as repeater operator, is not ultimately responsible.
Let us know how the infonerd thing goes. :)
--Bart
On 2/21/2013 7:21 PM, Benjamin Krueger wrote:
I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
Just coming in the middle of this. What about using certificates in some way. You can issue certificates to legit hams ( users ) either by machine ( which is harder for machines that do not have that fuctionality) or by user. No encryption needed. In other words, two factor authentication, if you also have to log into the network. Basically a enterprise solution, or is that to difficult to manage? Steve N0FPF On Feb 21, 2013, at 7:46 PM, Bart Kus <me@bartk.us> wrote: Good direction, but I'd drop the requirement for policing the network by actively preventing hams from using crypto. Hams are supposed to be self-policing, and we'll be engaging a losing battle, and inviting exploits. Let's just provide the tools to play nice. If people wanna run astray of rules, HamWAN as repeater operator, is not ultimately responsible. Let us know how the infonerd thing goes. :) --Bart On 2/21/2013 7:21 PM, Benjamin Krueger wrote: I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates. I'm going to speak to some infosec geeks about this tonight NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto. -- Benjamin _______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Use certificates where? In what protocol? On Thu, Feb 21, 2013 at 7:52 PM, steve monsey <stevewa206@gmail.com> wrote:
Just coming in the middle of this. What about using certificates in some way. You can issue certificates to legit hams ( users ) either by machine ( which is harder for machines that do not have that fuctionality) or by user. No encryption needed. In other words, two factor authentication, if you also have to log into the network. Basically a enterprise solution, or is that to difficult to manage?
Steve N0FPF
On Feb 21, 2013, at 7:46 PM, Bart Kus <me@bartk.us> wrote:
Good direction, but I'd drop the requirement for policing the network by actively preventing hams from using crypto. Hams are supposed to be self-policing, and we'll be engaging a losing battle, and inviting exploits. Let's just provide the tools to play nice. If people wanna run astray of rules, HamWAN as repeater operator, is not ultimately responsible.
Let us know how the infonerd thing goes. :)
--Bart
On 2/21/2013 7:21 PM, Benjamin Krueger wrote:
I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
IPSec(AH) is a great solution for protecting the availability of services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers. Regarding key exchange, it turns out that the ARRL already has a PKI trust infrastructure in place. The ARRL Logbook of the World<http://www.arrl.org/logbook-of-the-world>service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do. The certificates are intended to be used for signing logbook entries, but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption. The same rsa key pair can use used for SSH auth as well, but from my investigations, it would require custom binaries on both the client and server side to disable the encryption. It's a cumbersome hurdle that we wouldn't want to make people jump through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;) -Cory *infosec geek* On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <ben.krueger@gmail.com>wrote:
I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322). On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm> wrote:
IPSec(AH) is a great solution for protecting the availability of services
on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers.
Regarding key exchange, it turns out that the ARRL already has a PKI
trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do.
The certificates are intended to be used for signing logbook entries, but
if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption.
The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and server side to disable the encryption.
It's a cumbersome hurdle that we wouldn't want to make people jump
through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;)
-Cory *infosec geek*
On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <ben.krueger@gmail.com>
wrote:
I think we can solve a lot of our crypto-regulation problems if we
explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's
still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
When you use someone's public key to establish a secure connection with them, you need a way to verify that it belongs to the party you intend and not an imposer. One way to do that is to make the public keys available ahead of time via a trusted source (such as DNSSEC). However, certificates are an alternative way of doing that without communicating in advance or with any other online system. Each party trusts one or more root certificate authorities and the CAs vouch for someone by signing their public key. Each host knows that "if the root trusts who I'm talking to, they must be legit". A certificate is simply a public key with identifying information which is then signed by a trusted third party. On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <ben.krueger@gmail.com>wrote:
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322).
On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm> wrote:
IPSec(AH) is a great solution for protecting the availability of
services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers.
Regarding key exchange, it turns out that the ARRL already has a PKI
trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do.
The certificates are intended to be used for signing logbook entries,
but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption.
The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and server side to disable the encryption.
It's a cumbersome hurdle that we wouldn't want to make people jump
through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;)
-Cory *infosec geek*
On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <ben.krueger@gmail.com>
wrote:
I think we can solve a lot of our crypto-regulation problems if we
explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's
still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
This would work fine as well. On Fri, Feb 22, 2013 at 12:14 AM, Cory (NQ1E) <cory@nq1e.hm> wrote:
When you use someone's public key to establish a secure connection with them, you need a way to verify that it belongs to the party you intend and not an imposer. One way to do that is to make the public keys available ahead of time via a trusted source (such as DNSSEC). However, certificates are an alternative way of doing that without communicating in advance or with any other online system. Each party trusts one or more root certificate authorities and the CAs vouch for someone by signing their public key. Each host knows that "if the root trusts who I'm talking to, they must be legit". A certificate is simply a public key with identifying information which is then signed by a trusted third party.
On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <ben.krueger@gmail.com>wrote:
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322).
On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm> wrote:
IPSec(AH) is a great solution for protecting the availability of
services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers.
Regarding key exchange, it turns out that the ARRL already has a PKI
trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do.
The certificates are intended to be used for signing logbook entries,
but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption.
The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and server side to disable the encryption.
It's a cumbersome hurdle that we wouldn't want to make people jump
through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;)
-Cory *infosec geek*
On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <
ben.krueger@gmail.com> wrote:
I think we can solve a lot of our crypto-regulation problems if we
explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's
still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
Yes, that is how a lot of organizations use it. One of the issues is with small gadgets that do not have that much sophistication in their OS. An echo link gadget probably does not have the facility to do a certificate. Steve On Feb 22, 2013, at 1:30 AM, Benjamin Krueger <ben.krueger@gmail.com> wrote: This would work fine as well. On Fri, Feb 22, 2013 at 12:14 AM, Cory (NQ1E) <cory@nq1e.hm> wrote:
When you use someone's public key to establish a secure connection with them, you need a way to verify that it belongs to the party you intend and not an imposer. One way to do that is to make the public keys available ahead of time via a trusted source (such as DNSSEC). However, certificates are an alternative way of doing that without communicating in advance or with any other online system. Each party trusts one or more root certificate authorities and the CAs vouch for someone by signing their public key. Each host knows that "if the root trusts who I'm talking to, they must be legit". A certificate is simply a public key with identifying information which is then signed by a trusted third party.
On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <ben.krueger@gmail.com>wrote:
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322).
On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm> wrote:
IPSec(AH) is a great solution for protecting the availability of
services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers.
Regarding key exchange, it turns out that the ARRL already has a PKI
trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do.
The certificates are intended to be used for signing logbook entries,
but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption.
The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and server side to disable the encryption.
It's a cumbersome hurdle that we wouldn't want to make people jump
through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;)
-Cory *infosec geek*
On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <
ben.krueger@gmail.com> wrote:
I think we can solve a lot of our crypto-regulation problems if we
explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's
still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I suspect that for those kinds of devices, we would do well to provide them with a proxy service they can use. It won't have any integrity guarantees, but as long as they understand that they it should be ok. On Fri, Feb 22, 2013 at 7:03 AM, steve monsey <stevewa206@gmail.com> wrote:
Yes, that is how a lot of organizations use it. One of the issues is with small gadgets that do not have that much sophistication in their OS. An echo link gadget probably does not have the facility to do a certificate.
Steve
On Feb 22, 2013, at 1:30 AM, Benjamin Krueger <ben.krueger@gmail.com> wrote:
This would work fine as well.
On Fri, Feb 22, 2013 at 12:14 AM, Cory (NQ1E) <cory@nq1e.hm> wrote:
When you use someone's public key to establish a secure connection with them, you need a way to verify that it belongs to the party you intend and not an imposer. One way to do that is to make the public keys available ahead of time via a trusted source (such as DNSSEC). However, certificates are an alternative way of doing that without communicating in advance or with any other online system. Each party trusts one or more root certificate authorities and the CAs vouch for someone by signing their public key. Each host knows that "if the root trusts who I'm talking to, they must be legit". A certificate is simply a public key with identifying information which is then signed by a trusted third party.
On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <ben.krueger@gmail.com
wrote:
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322).
On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm> wrote:
IPSec(AH) is a great solution for protecting the availability of
services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers.
Regarding key exchange, it turns out that the ARRL already has a PKI
trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do.
The certificates are intended to be used for signing logbook entries,
but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption.
The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and server side to disable the encryption.
It's a cumbersome hurdle that we wouldn't want to make people jump
through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;)
-Cory *infosec geek*
On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <
ben.krueger@gmail.com> wrote:
I think we can solve a lot of our crypto-regulation problems if we
explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication. That's
still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
Why provide a proxy that ultimately does nothing? Just don't use IPSec on the devices that can't support it, and accept the situation. --Bart On 02/22/2013 02:17 PM, Benjamin Krueger wrote:
I suspect that for those kinds of devices, we would do well to provide them with a proxy service they can use. It won't have any integrity guarantees, but as long as they understand that they it should be ok.
On Fri, Feb 22, 2013 at 7:03 AM, steve monsey <stevewa206@gmail.com <mailto:stevewa206@gmail.com>> wrote:
Yes, that is how a lot of organizations use it. One of the issues is with small gadgets that do not have that much sophistication in their OS. An echo link gadget probably does not have the facility to do a certificate.
Steve
On Feb 22, 2013, at 1:30 AM, Benjamin Krueger <ben.krueger@gmail.com <mailto:ben.krueger@gmail.com>> wrote:
This would work fine as well.
On Fri, Feb 22, 2013 at 12:14 AM, Cory (NQ1E) <cory@nq1e.hm <mailto:cory@nq1e.hm>> wrote:
When you use someone's public key to establish a secure connection with them, you need a way to verify that it belongs to the party you intend and not an imposer. One way to do that is to make the public keys available ahead of time via a trusted source (such as DNSSEC). However, certificates are an alternative way of doing that without communicating in advance or with any other online system. Each party trusts one or more root certificate authorities and the CAs vouch for someone by signing their public key. Each host knows that "if the root trusts who I'm talking to, they must be legit". A certificate is simply a public key with identifying information which is then signed by a trusted third party.
On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <ben.krueger@gmail.com <mailto:ben.krueger@gmail.com>> wrote:
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322).
On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm <mailto:cory@nq1e.hm>> wrote: > > IPSec(AH) is a great solution for protecting the availability of services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers. > > Regarding key exchange, it turns out that the ARRL already has a PKI trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do. > > The certificates are intended to be used for signing logbook entries, but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption. > > The same rsa key pair can use used for SSH auth as well, but from my investigations, it would require custom binaries on both the client and server side to disable the encryption. > > It's a cumbersome hurdle that we wouldn't want to make people jump through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;) > > -Cory > *infosec geek* > > > > On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <ben.krueger@gmail.com <mailto:ben.krueger@gmail.com>> wrote: >> >> I think we can solve a lot of our crypto-regulation problems if we explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates. >> >> I'm going to speak to some infosec geeks about this tonight >> >> NB: This doesn't handle initial network access authentication. That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto. >> >> -- >> Benjamin >> >> _______________________________________________ >> PSDR mailing list >> PSDR@hamwan.org <mailto:PSDR@hamwan.org> >> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org >> > > > _______________________________________________ > PSDR mailing list > PSDR@hamwan.org <mailto:PSDR@hamwan.org> > http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org >
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin _______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
I don't know, without testing, whether there are issues with non-ipsec enabled hosts communicating with ipsec enabled hosts. On Fri, Feb 22, 2013 at 3:24 PM, Bart Kus <me@bartk.us> wrote:
Why provide a proxy that ultimately does nothing? Just don't use IPSec on the devices that can't support it, and accept the situation.
--Bart
On 02/22/2013 02:17 PM, Benjamin Krueger wrote:
I suspect that for those kinds of devices, we would do well to provide them with a proxy service they can use. It won't have any integrity guarantees, but as long as they understand that they it should be ok.
On Fri, Feb 22, 2013 at 7:03 AM, steve monsey <stevewa206@gmail.com>wrote:
Yes, that is how a lot of organizations use it. One of the issues is with small gadgets that do not have that much sophistication in their OS. An echo link gadget probably does not have the facility to do a certificate.
Steve
On Feb 22, 2013, at 1:30 AM, Benjamin Krueger <ben.krueger@gmail.com> wrote:
This would work fine as well.
On Fri, Feb 22, 2013 at 12:14 AM, Cory (NQ1E) <cory@nq1e.hm> wrote:
When you use someone's public key to establish a secure connection with them, you need a way to verify that it belongs to the party you intend and not an imposer. One way to do that is to make the public keys available ahead of time via a trusted source (such as DNSSEC). However, certificates are an alternative way of doing that without communicating in advance or with any other online system. Each party trusts one or more root certificate authorities and the CAs vouch for someone by signing their public key. Each host knows that "if the root trusts who I'm talking to, they must be legit". A certificate is simply a public key with identifying information which is then signed by a trusted third party.
On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger < ben.krueger@gmail.com> wrote:
The problem isn't generating keys and certificates, but distributing them so that hosts which are strangers have a way to authenticate each other. So far dnssec looks like a candidate. Check out the rfc for opportunistic encryption (rfc 4322).
On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory@nq1e.hm> wrote:
IPSec(AH) is a great solution for protecting the availability of
services on the network. Unfortunately, it does nothing to protect layers 1 and 2 (the more important ones to the RF rules). Arguably, only having layer 2 access to a node will not get you very much, but it's worth noting. Because of this 802.1x will likely be the way to go and I'm currently investigating the details of what it would look like for our specific use case. Short of customizing the RF spec, there's not really much else we could do at the lower layers.
Regarding key exchange, it turns out that the ARRL already has a PKI
trust infrastructure in place. The ARRL Logbook of the World service requires that hams jump though hoops to prove their licence identity and it issues them a certificate with their call sign when they do.
The certificates are intended to be used for signing logbook entries,
but if you know what you're doing, there's nothing that would prevent you from exporting the key pair and using it for other things. A server that trusts the ARRL root CA certificate would be able to prove the identity and call sign of any user connecting to it with such a user cert. I setup a test server for this a while back and it's still up and running at https://mutual.hamauth.com/ If you have such a cert and imported it into your browser, you could try it out. I also have one running at https://tls-test.nq1e.hm/ that you may not be able to connect to because it's also using the little known null (no) encryption cipher spec in SSL which browsers don't support by default (it can be enabled in firefox or opera). This means that if the client was properly configured, we could use SSL servers for specific services on the wireless network for authentication, authorization and integrity without encryption.
The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and server side to disable the encryption.
It's a cumbersome hurdle that we wouldn't want to make people jump
through, but if it were more popular, it could be used for just about anything. You should all definitely sign up for LotW just in case (since it can take a week or two to get verified). ;)
-Cory *infosec geek*
On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <
ben.krueger@gmail.com> wrote:
I think we can solve a lot of our crypto-regulation problems if we
explore IPSec in Authentication Header Transport mode. This signs every IP packet which gets us connection integrity, origin authentication, and replay protection without encrypting anything. Then we only have to take very basic measures to ensure folks don't intentionally or unintentionally make encrypted connections (over SSL, SSH, or other commonly encrypted protocols). The only outstanding question then is how to handle IKE (key exchange) in an automated way with certificates.
I'm going to speak to some infosec geeks about this tonight
NB: This doesn't handle initial network access authentication.
That's still a problem to be solved, possibly with 802.1X, though that has its own problem since RouterOS only supports TLS-EAP which incorporates crypto.
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/22/2013 07:57 PM, Benjamin Krueger wrote:
I don't know, without testing, whether there are issues with non-ipsec enabled hosts communicating with ipsec enabled hosts.
Opportunistic mode should take care of that. "Try to set up an encrypted connection; if not, try to set up an authenticated connection; failing that, try to just set up a connection." Just make sure that your failure case isn't "abort connection." - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "'PC LOAD LETTER'?! What the /[a-z]{4}/ does that mean??" --Michael Bolton, _Office Space_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEpcoQACgkQO9j/K4B7F8EGcACfUuR1kOUXYC1WY/ie+NXVZW5O S+UAoITWo+eVR/TY00rFIlj87DYLLOwV =eXbz -----END PGP SIGNATURE-----
I don't know, without testing, whether there are issues with non-ipsec enabled hosts communicating with ipsec enabled hosts.
On the whole subject in general.... We (HAMS) have been doing Internet connections on Ham frequencies for over 20 years. Every time something new comes up or a new group wants to do it (HamWan...) these same discussions are held. Of course with the rate that technology is advancing the descussions are more involved and sophisticated every iteration. Bottom line from the high water mark - there's never been an issue or a problem. Of course today there is far more speed available to do cool (and sometimes questionable) things. Which comes back to a even more basic issue. Why bother with Part 97 (HAM) use at all unless using frequencies that are not available to Part 15? Part 97 only brings issues, discussions and drawbacks... 73 Bill - WA7NWP
participants (6)
-
Bart Kus -
Benjamin Krueger -
Bill Vodall -
Cory (NQ1E) -
steve monsey -
The Doctor