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

[pfbram at comcast.net]

Just thinking out loud here, but how about a separate authentication/verification system in which I/SGATE operators login to an SSL web-based application and provide something like callsign, current grid, IS passcode and the current IP address of their IGATE. A T2 server must see data coming from that IP(s), and perhaps rough lat/long coordinates, or it is rejected. UDP contains source IP. 

A strategy like this would have its problems, especially with mobile (wi-fi hotspots) and DHCP situations. It would be irritating to update your IP periodically, and it's possible that your IP could change without your knowledge -- throwing your IGATE offline. And it would require a centralized database. 

Regards, 
Paul / KD0KZE 

----- Original Message -----
From: "Ya'akov Sloman" <yaakov at sloman.me> 
To: "TAPR APRS Mailing List" <aprssig at tapr.org> 
Sent: Sunday, March 30, 2014 5:33:29 AM 
Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption 

I'd like to make a couple of suggestions for consideration. 

The need for TCP might be reduced to an authentication handshake rather than every frame. If something akin to SMTP AUTH is used, along with some other *temporary* form of shared secret exchanged at the time of the authentication, and combined with the source address, it would reduce the possible abuse window to the horizon of the authenticated "session". 

That is, using TLS or equivalent, the station can authenticate to the server using TCP. It is handed an expiring secret, and the session state is retained by the server which includes the call, secret, and source address. After that, UDP frames are used as usual, with the secret acting just as the current passcode does, but with expiration. 

It might be beneficial to use the model of DHCP and have the client request a new secret (via the TCP mechanism) at 1/2-expiry. 

The method of authentication *could* be PKI or something else since TLS will hide the exchange. PKI has the advantage of not requiring the maintenance of a password file and managing access to it. 

There is also the possibility of WoT (Web of Trust) using PGP (or GnuPG, most likely) to decentralize the CA. If we used some method to record trusted signers (which could be completely open since it is not, in itself, confidential), and we required one or more signatures from previously trusted operators, no CA would be needed. 

These are just some thoughts, for what they are worth. 

Ya'akov 
N1EWO 

_______________________________________________ 
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/9dc71480/attachment.html>