[HamWAN PSDR] Let's talk about identity
Bart Kus
me at bartk.us
Thu Apr 6 15:24:03 PDT 2017
I suppose we may want to amend HamWAN's official Mission statement to
better reflect the recent work in developing software and networking
standards. The stuff we released so far in this realm is:
* SSH Without Encryption
<http://hamwan.org/Standards/Network%20Engineering/Authentication/SSH%20Without%20Encryption.html>
<http://hamwan.org/Standards/Network%20Engineering/Authentication/SSL%20without%20Encryption.html>
* SSL Without Encryption
<http://hamwan.org/Standards/Network%20Engineering/Authentication/SSL%20without%20Encryption.html>
* Open Peering Policy
<http://hamwan.org/Labs/Open%20Peering%20Policy.html>
* High Availability
<http://hamwan.org/Standards/Network%20Engineering/High%20Availability.html>
* Some other Server suggestions
<http://hamwan.org/Standards/Network%20Engineering/Cell%20Site%20Configuration/Servers.html>
* Point to Multipoint Authentication
<http://hamwan.org/Standards/Network%20Engineering/Point%20to%20Multipoint%20Authentication.html>
* Quality of Service
<http://hamwan.org/Standards/Network%20Engineering/Quality%20of%20Service.html>
Some of these are better than others. Many of these need more work.
Specifically, only the SSH solution is "finished", I think. The
unpublished work going on right now is focused on automation and
robustness of network services. I got some good engagement in the
previous thread I sent out on distributed filesystem implementations
(most of it in private email), and that left me with a few options to
verify in the lab and on the HamWAN network. This identity thread
doesn't quite have the same expert engagement though, so the quest
continues.
At the inevitable risk of offense, I don't see what ARETF offers to be
leveraged. Having surfed the site, forum and github repo, it's pretty
much empty. What this work requires is active, dedicated engineers who
have a deep understanding of how things work in this space. Show me
where THOSE people are, and I'll happily join the group.
Why can't ARETF's mission be executed within HamWAN? We have a small
but growing set of engineers who are well versed in the digital world.
We also have the added benefit of real-world use cases, so you don't
fall into the pit of designing-for-everybody on your first iteration.
Having said all that, I don't think the entirety of what's needed to
service emcomm (and likely even ham) users can be implemented in
HamWAN's current organizational model. Motivating said skilled
engineers to execute consistently and on-time (or even at all) has been
one major impediment to success. Lately I've been studying the
viability of remunerating engineering work in this problem space. The
most surprising finding to date is that some folks have a philosophical
opposition to getting paid for their work product in this problem
space. Feel free to contact me privately (goes for anyone) if you're
interested in this latest viability study of mine.
--Bart
On 4/6/2017 1:15 PM, Kenny Richards wrote:
> It would be great if we could leverage the ARETF for this kind of
> discussion. Bryan and I dreamed it up for this kind of situation, but
> so far we have been a solution looking for a problem.
>
> Even if we decided to use 'off the shelf' solutions, the configuration
> changes for amateur radio being documented is still goodness.
>
> Is the right next step just laying some of this ground work and
> defining the scope problems we need to address?
>
> Thanks
> Kenny
>
>
> On Sat, Apr 1, 2017 at 1:59 PM, Cory (NQ1E) <cory at nq1e.hm
> <mailto:cory at nq1e.hm>> wrote:
>
> This is the first topic we were hoping to tackle if we could get
> some interest behind the ARETF <http://aretf.org/>. I made a post
> there a couple years ago to try to get the ball rolling, but
> without the help of others I haven't been able to stay focused on
> this topic due to many different things that demand my time.
>
> I'll start by reposting my introduction to terms. ;)
>
>
> ----------------------------------
>
> I'll start by clarifying some terms so we can further discuss
> these matters with the appropriate context.
>
> When people refer to "secure" communication, they're typically
> implying these three distinct features:
>
> *
>
> Privacy - Preventing third parties from seeing what is being
> communicated.
>
> *
>
> Integrity - Assurance that the message received was from the
> sender and not tampered with in transit
>
> *
>
> Authentication - Assurance that the sender is who you expect
> them to be and not an impostor
>
> When providing security for a system, you also need to consider:
>
> *
>
> Authorization - Determining if the identified sender is
> allowed to perform the action they are requesting.
>
> In amateur radio, we want to be able to use all of the security
> features above except for privacy. It's a common misconception in
> the US that FCC part 97 prevents the use of encryption and
> therefore most security features aren't available to us. However,
> what part 97 actually prohibits is "messages encoded for the
> purpose of obscuring their meaning." It's important to keep this
> distinction in mind when developing best practices and
> communicating them to users who may not understand the difference.
>
> We should also try to avoid rat-holing any discussions with debate
> on whether privacy *should* be allowed as that isn't productive
> for our goals. It's also likely what contributed to past failures
> on this subject.
>
> Luckily, many technologies already support these features without
> privacy which means we don't need to start from scratch.
> Unfortunately, privacy is the one thing most people think of when
> it comes to security. Therefore, our use-cases don't tend to be
> well documented or understood. That's what I hope we get a chance
> to fix.
>
> -Cory
> NQ1E
>
> ----------------------------------
> 2015-05-18
> https://forum.aretf.net/viewtopic.php?pid=10#p10
> <https://forum.aretf.net/viewtopic.php?pid=10#p10>
>
>
> On Sat, Apr 1, 2017 at 1:19 PM, Bart Kus <me at bartk.us
> <mailto:me at bartk.us>> wrote:
>
>
>
> No, not that kind of identity. Digital identity. Used to
> inform networks and computers about who you are. In my brief
> research on this, Wikipedia has listed a few systems:
>
> 1. SAML
> 2. OAuth
> 3. OpenID
> 4. CAS
>
> There are of course other systems, such as X509 certificates,
> or just plain old trusted keys or fingerprints. The question
> is, which of these systems are appropriate for use on Part 97
> airwaves?
>
> The big P97 restriction we have is no use of secrecy or
> encryption. Early on we realized this means any system which
> relies on shared secrets (such as passwords) is not going to
> work well. One system that does work really well is
> public/private key based authentication. SSH key
> authentication and TLS client certificate authentication work
> really well because of this. However, those systems are not
> without problems. Both of them need to have the encryption
> option turned off, which requires a custom ssh client and
> server for SSH, and is nearly impossible to do with any modern
> web browser for TLS. Other applications that use TLS will
> also have the same challenge.
>
> I'd like to identify some acceptable identity systems for web
> browsers and web applications. It would be great if they
> could also be used for email clients (Thunderbird, Evolution,
> KMail, etc), and other applications like file shares.
>
> I haven't looked into security tokens at all yet, but those
> may work. That is, to plug a token into USB or tap it via NFC
> (cell phone case), and have yourself identified.
>
> Is anyone aware of which systems may be compatible with Part
> 97 and work in a user-friendly way?
>
> --Bart
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
> http://mail.hamwan.net/mailman/listinfo/psdr
> <http://mail.hamwan.net/mailman/listinfo/psdr>
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
> http://mail.hamwan.net/mailman/listinfo/psdr
> <http://mail.hamwan.net/mailman/listinfo/psdr>
>
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20170406/ac2f76a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 13670 bytes
Desc: not available
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20170406/ac2f76a9/attachment-0001.jpe>
More information about the PSDR
mailing list