[aprssig] APRS-IS authentication (Was: APRS-IS Passcode Generator On-Line)

[Lynn W. Deffenbaugh (Mr)]

Georg Lukas DO1GL wrote:
>
> I am really sorry for the confusion I caused to you, and I would have
> been really glad to hear from you directly. I can remove the links to
> your site if you wish so (or mirror the data on my own if you are
> concerned about the traffic). However, as you pointed out, the
> information is freely available to anyonce capable of using google ;-)
>   

Not if we can manage to get the on-line password generator hosts to take 
their page down.  That will at least make it harder, but not impossible 
to locate callpass.c in the xastir distribution and compile it yourself.

> My primary concern with this reply however is the access barrier to
> APRS-IS. Once released to Android Market, APRSdroid will be available to
> a huge audience, consisting mainly of non-hams. Right now, the access
> barrier consists of a warning dialog at the first program start, stating
> that it is probably illegal to use without a license, and the
> requirement to figure out the APRS-IS passcode.
>   

It is exactly that "huge audience" that prompted this thread to start with.

> On the other hand, requiring an authentication mechanism comparable to
> the one on EchoLink just to access a 16-bit hash number is neither
> efficient nor adequate. After all, other applications are just taking
> the callsign and silently calculate the passcode.
>   

I'm only aware of one of those myself.  And it's on a similar platform 
with similar distribution potential, but fortunately not extremely 
attractive I'm told.  I don't use that platform personally and am 
commenting on hear-say, never a good idea.

> What would be the adequate level of checking for this (or any other)
> APRS-IS application?
>
> The options I see so far are:
>
>  * No checking, automatic passcode calculation (too easy for accidental
>         abuse by non-hams?)
>   

Cast my vote against this one!

>  * Match the callsign against a regular expression
>   

This is being proposed within the APRS-IS network servers, but could be 
exclusive of callsign patterns that the program's author was unaware 
of.  Also, if the client itself matches and confirms validity, 
brute-force attempts are easier.  If the back-end quietly doesn't accept 
updates, but still provides a feed, it can be harder, but again not 
impossible to figure out a pattern match.


>  * Require entry of the passcode, providing an online form for passcode
>        generation
>   

This is no different than the first one so it also gets a "No" vote from 
me (if you're tallying).

>  * Provide an online form requiring name, callsign and email address and
>        logging the data for abuse management
>   

Anything on-line is too easily spoofed.  Unless you're building off of a 
trust network like Google or Yahoo or something, but even that is weak 
protection.

>  * Require passcodes to be requested by e-mail (adds much work but does
>        not really prevent callsign stealing)
>   

This is the approach previously recommended for APRS-IS client software 
authors and the one that I personally follow for APRSISCE/32 and now for 
APRSBB on behalf of KJ4HPQ.  Even if all 100,000 hams (or whatever the 
number is) actually requested a passcode, this is still not unworkable.

>  * Perform an EchoLink-like authentication check
>   

While I'd love for this to be the case, the non-centralized insecurity 
of the APRS-IS network itself doesn't seem to lend itself to this level 
of complexity.

> I'd be glad to hear opinions and suggestions from this community!
>   

That's my open opinion.  Take it for whatever you consider it to be worth.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32