Proposal for password authentication

[nivex]

I propose the IP Networking Control Packets specification be extended with two additional types to provide optional password authentication. This will allow operators of servers to choose whether they wish to have additional security without changes to existing services.

---

ACKA

Bytes
0-3   Magic - ASCII "ACKA"
4-7   4 byte salt

Server may, upon receipt of a valid CONN command, respond with this type packet indicating that the callsign presented was valid but this connection requires authentication.

The salt must be different for each authentication attempt and should be acquired from a source with sufficient entropy.

AUTH

Bytes
0-3   Magic - ASCII "AUTH"
4-36  32 byte digest

Client must, upon reciept of an ACKA packet in response to a CONN command, respond with this type packet.

The digest shall be the SHA256 hash of the salt and the user's password.

Server must respond with an ACKN packet if the authentication is successful or NACK if it is not.
Server should also terminate the connection if the authentication is unsuccessful.

---

Example successful exchange with a salt of 0x31323334 and a base40 encoded callsign N8VNR:

CONN<callsign> => 434f4e4e000002cd5b06
ACKA<salt>     <= 41434b4131323334
AUTH<digest>   => 415554488d295b172e388c8c99fa16ac5a5fbcdc710279d9ea23a67e73dbae6fbaf515b9
ACKN<callsign> <= 41434b4e000002cd5b06

Points for discussion:

• There are newer algorithms than SHA256 available for password hashing. I chose this because it's what MMDVMHost uses.
• Should ACKA include the callsign before the salt as its cousin ACKN does?

[nivex]

The spec was just updated to remove the callsign in ACKN packets, so that's no longer a concern.