[aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

[pfbram at comcast.net]

The SSL would be for a (separate) verification/authentication system, not the APRS packets themselves, to ensure that the user's app. password doesn't travel plain-text, and is not sniffable. It would be largely a self-policing model. Each operator would maintain his own profile, keeping it current with his callsign, passcode, his IGATE's current IP address, etc. The only thing that would need to be added to the T2 network is (a) noting the IP in the incoming packets and (b) some sort of API to ensure that the IP matches the one noted as "valid+current" by the operator in a hypothetical profile/validation system. I agree, this approach has its problems. 

I've worked with SSL, Shibboleth, made my own certs/CA's, etc. and other systems professionally for several years. I'd definitely advise against Shibboleth due to its complexity, moving parts, etc. 

Usually it's a matter of approaching the "business problem" itself from a different angle, not just throwing technology at it. Who knows? Maybe there is something to be gained with VPN's, SSL + ssh keys, GnuPG, etc. Certainly with security there is no such thing as a single magic bullet. 

But if you could better manage your own IGATE/call against someone spoofing it -- and have a tool on hand to easily block out/filter troublesome stations (point-and-click), then you'd have a more resilient system -- driven mainly by (a) more information available to you and (b) self-policing. 

Paul / KD0KZE 

----- Original Message -----
From: "Jason KG4WSV" <kg4wsv at gmail.com> 
To: "TAPR APRS Mailing List" <aprssig at tapr.org> 
Sent: Monday, March 31, 2014 4:28:15 PM 
Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption 

On Mon, Mar 31, 2014 at 3:47 PM, <pfbram at comcast.net> wrote: 
> Just thinking out loud here, but how about a separate 
> authentication/verification system in which I/SGATE operators login to an 
> SSL 

Involving SSL doesn't magically make a system secure. SSL is about 
encrypting traffic in flight - that's it. Forcing use of SSL can 
provide some measure of authentication, based on the whole CA system. 

> And it would require a 
> centralized database. 

That little aside _is_ the problem. Who do you trust? Who do you 
trust to keep a list of people that can be trusted? 

For any authentication system to work, someone has to keep a list, and 
then be willing to deal with all the extra work involved in certifying 
everyone on the list. 


I'm with Steve K4HG on this one - as far as APRS is concerned all I'm 
seeing are solutions in search of problems. 

-Jason 
kg4wsv 
_______________________________________________ 
aprssig mailing list 
aprssig at tapr.org 
http://www.tapr.org/mailman/listinfo/aprssig 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140331/4d658e82/attachment.html>