[HamWAN PSDR] Let's talk about identity
Kenny Richards
richark at gmail.com
Mon Apr 10 11:24:57 PDT 2017
(Just discovered this stuck in my drafts folder)
Bart,
The reason we tried to start the ARETF was to have a place to work out and
store ham radio standards, that was independent of any particular group. I
completely agree that HamWAN could 'host/manage' this effort, but what
about other areas in ham radio that may have needs for some of the work?
Would HamWAN be willing to take input if there was APRS or PACTOR needs? I
am pretty sure HamWAN wouldn't be interesting in hosting any other efforts.
I agree there isn't much benefit right now to the ARETF, it needed
something to kick off the process and build out how to 'standardized' a ham
radio related thing. I failed at finding that first thing, but maybe this
would be it?
Thanks
Kenny
On Thu, Apr 6, 2017 at 3:24 PM, Bart Kus <me at bartk.us> wrote:
> 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> 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
>>
>>
>> On Sat, Apr 1, 2017 at 1:19 PM, Bart Kus <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
>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>
>>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
>>
>
>
> _______________________________________________
> PSDR mailing listPSDR at hamwan.orghttp://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/20170410/6fa4e268/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/20170410/6fa4e268/attachment-0001.jpe>
More information about the PSDR
mailing list