ARIM Messaging Program v1.2


Bob NW8L
 

Hello,
 
ARIM v1.2 is available for download:
 
https://www.whitemesa.net/arim/arim.html#inst
 
Includes new Mutual Authentication feature for ARQ mode. See
change log extract below.
 
Details in change log excerpt below. Special thanks to Doug WB6VAC
for help in beta testing.
 
Files are also available at the ardop applications Files area at
groups.io:
 
https://ardop.groups.io/g/applications/files
 
and in the Files area at the arim-ham Yahoo group:
 
https://groups.yahoo.com/neo/groups/arim-ham/files
 
Station NW8L will be on dial 14.066 in daytime, 7.101 at night and
sometimes 10.131 for a while in-between, for testing.
 
73, Bob NW8L
 
v1.2  27Jan2018
---------------
1. Introduce optional Mutual Authentication feature used to verify
   the identities of the stations in an ARQ session. This works by
   making each station prove to the other that it possesses a shared
   secret (password) known only to the two stations involved. This is
   done using a Digest Access Authentication scheme very similar to
   that specified in RFC 2069 [1] with the exception that the MD5 hash
   function is replaced by the more modern and secure Blake2 [2] hash
   function. The exchange of proofs is accomplished without sending
   the password itself over the air. The process is automatic and
   requires no operator intervention. This feature can be used to:
     * verify the identity of the station you connect to in ARQ mode.
     * grant another station access to controlled resources located on
       your station.
   --------------------------
   ARQ session authentication
   --------------------------
   Once an ARQ connection is established, the operator can invoke the
   mutual authentication process manually using the '/auth' command.
   If it succeeds, the identity of the remote station is proven and
   the operator can read, upload or download files with confidence. If
   it fails, because one station or the other doesn't know the shared
   secret (password), the operator is presented with a warning
   message and given the choice of either continuing or terminating
   the ARQ session.
   ------------------
   ARQ access-control
   ------------------
   Shared files directories at a station can be designated as
   "access-controlled" with the 'ac-files-dir' parameter in the ARIM
   configuration file. These resources are available only to stations
   that successfully authenticate themselves in an ARQ session. By
   default, the authentication process is triggered automatically on
   the first attempt by a station to access a controlled resource.
   However, the operator can issue the '/auth' command pre-emptively
   to authenticate with the remote station before attempting to access
   controlled directories and their contents. If mutual authentication
   is successful, the command is re-sent and subsequent accesses of
   controlled resources on the remote station proceed normally.
 
   Note that shared files directories defined by 'add-files-dir'
   parameters in the ARIM configuration file are not
   access-controlled. These are accessible to any station in ARQ and
   FEC mode operations. Likewise, the root shared files directory is
   always accessible to any station for file listing, uploads and
   downloads.
   ----------------------------------------------
   The authentication challenge/response protocol
   ----------------------------------------------
   a. The process begins when the operator at one station (the
   "client"), connects to another station (the "server") and:
      * attempts to access a controlled resource for the first time
   or
      * sends the '/auth' command
 
   b. At the server station, ARIM receives the command and recognizes
   that authentication is required. It searches its password digest
   file for an entry with the client station's call sign as the
   "client" and its own call sign as the "server". If it cannot find
   such an entry, it responds with '/EAUTH' and the operator at the
   client station is informed that authentication has failed. If ARIM
   does find such an entry, it responds with an authentiation
   "challenge" in the form of the '/A1' command. The challenge
   includes an opaque "nonce", a token whose content it controls and
   which must be incorporated into the response made by the client
   station.
 
   c. At the client station, ARIM receives the '/A1' command. It
   searches its password digest file for an entry with the client
   station's call sign as the "client" and its own call sign as the
   "server". If it cannot find such an entry, it responds with
   '/EAUTH' and the operator at the client station is informed that
   authentication has failed. If the needed entry is found, ARIM
   computes a response token which proves that it knows the shared
   secret. The response is H(HA1:nonce:HA2) where:
      H(x) is: the Blake2 hash of an array of data 'x'.
      HA1 is: H(client_call:server_call:password), the password hash
         token stored in the password digest file at the client
         station.
      nonce is: the token sent by the challenger to influence the
         response hash value.
      HA2 is: H(method:path) where 'method' is 'FPUT', 'FGET', 'FLIST'
         or 'FILE' and 'path' is the directory or file path referenced
         by the command.
   Thus the response to each challenge is unique, in a way dependent
   on the nature of the request and the 'nonce' issued by the
   challenger. This makes "replay" attacks difficult to mount and
   recovery of the password from the response computationally
   infeasible. ARIM sends the response token plus a challenge nonce to
   the server station in the form of the '/A2' command.
 
   d. At the server station, ARIM receives the '/A2' command and
   checks the challenge response token it contains. It does this by
   computing the response token it expects using the password digest
   token (HA1) stored in the password digest file it owns. It compares
   this with the response token received from the client station. If
   they don't match, then the client station must not have the same
   password digest that ARIM has stored locally. In this case ARIM
   will send '/EAUTH' to the client station where the operator will be
   informed that authentication has failed. If they match, then the
   client station has proven it's authenticity and ARIM will send a
   response the the challenge contained in the '/A2' command. As
   before, this is computed as H(HA1:nonce:HA2), using the challenge
   nonce received from the client station. ARIM sends this response to
   the client station in the form of the '/A3' command.
 
   e. At the client station, ARIM receives the '/A3' command and
   checks the challenge response token it contains. It does this by
   computing the response token it expects using the password digest
   token (HA1) stored in the password digest file it owns. It compares
   this with with the response token received from the server station.
   If they don't match, the server station must not have the same
   password digest that ARIM has stored locally. In this case ARIM
   will inform the operator that authentication has failed. If they
   match, then the server station has proven its authenticity and ARIM
   re-sends the command that triggered the process, unless it was the
   '/auth' command. In that case there is no work to do so ARIM simply
   sends the '/OK' response to signal that the mutual authentication
   is complete.
   To strike a reasonable balance between security and the "air time"
   cost of the challenge/response data exchanges, challenge nonces
   contain 6 bytes of data and the Blake2 response hash is truncated
   to 21 bytes, or 168 bits (big enough for excellent collision
   resistance). These are sent in base64 encoded form making the
   over-the-air sizes 8 and 28 bytes respectively.
   -------------------
   Password management
   -------------------
   Passwords are created at the ARIM command prompt with the 'passwd'
   command and stored in digest ("hashed") form in a file. Passwords
   are hashed with a "salt" (the call signs of the corresponding
   stations), so that any given password results in unique hash for
   different call sign pairs. This hash is identical to the 'HA1' term
   used in the digest authentication scheme, so it can be read out of
   the password digest file when needed, making it unnecessary to
   store the original password. Mathematically, the Blake2 hash
   function is a strong "one way" function; it is computationally
   infeasible to recover the password from the hash. Because the
   password hash is stored in a file the authentication process can
   operate without operator intervention; there's no need to remember
   and enter the password each time.
   ---------------------------
   Note on client/server roles
   ---------------------------
   In the context of an ARQ session, the term "client" refers to the
   station where an operator triggers the authentication process by:
      a. sending the '/auth' command to the other station
      b. attempting to access a controlled resource at the other
         when the ARQ session is not yet authenticated.
   When this happens the other station assumes the role of "server"
   and responds with an authentication challenge. These definitions
   imply that an operator is always present at the client station, but
   not at the server station, which is assumed to be operating
   automatically. However, once an ARQ connection is established
   between two stations, the operator at either end can seize the
   client role by being the first to trigger the mutual authentication
   process.
   For authentication to succeed, the 'passwd' command must be invoked
   at both stations like this:
      passwd client_call server_call some-password
   Let's assume that 'client-call' is KA8RYU, and 'server-call' is
   NW8L-1. So at each station 'passwd' is invoked like this:
      passwd KA8RYU NW8L-1 some-password
   Now KA8RYU can connect to NW8L-1 and successfully authenticate if
   challenged. However, this doesn't mean that the reverse is true:
   NW8L-1 can't connect to KA8RYU and do the same. For this to happen
   the 'passwd' command must be invoked at each station with NW8L-1 as
   the client:
      passwd NW8L-1 KA8RYU another-password
   Now either station can connect to the other and play the role of
   "client" to the other station's role of "server" in the
   authentication process.  If we read the password digest file at
   either station using the 'rp' command in the Shared Files viewer we
   see something like this:
      KA8RYU:NW8L-1:SEQo2oa1kOHXcBqRyDrn6wz7f8RDNAzNQAQxS31q
      NW8L-1:KA8RYU:CnCI11S3AxSzCAtgckzqM4pKrkr+wxWaIGT0E6EU
   There are two entries, one for KA8RYU as client to NW8L-1 as
   server, and another for NW8L-1 as client to KA8RYU as server. This
   allows both one-way and two-way relationships to be defined. For
   instance, a station serving as a document repository can issue
   passwords to multiple stations who connect to it as clients and
   access the controlled files it offers. However, no such password is
   issued to the repository station by the client stations; it cannot
   connect to any of them in the client role and authenticate for the
   purpose of accessing any controlled resources they publish.
   ----------
   References
   ----------
   [1] https://www.ietf.org/rfc/rfc2069.txt
   [2] https://www.ietf.org/rfc/rfc7693.txt
2. Add optional 'access control' feature. This allows you to
   designate shared files directories which are accessible only to
   authenticated stations in an ARQ session. If an ARQ session is not
   yet authenticated, the first attempt by an operator to access a
   controlled directory or file with the '/FPUT', '/FGET', '/FLIST' or
   '/FILE' commands triggers an authentication challenge from the
   remote station. If both stations possess the shared secret
   (password), then the authentication process succeeds and the
   command is executed. If it fails, the operator is presented with a
   warning message and given the choice of either continuing or
   terminating the ARQ session. The authentication process requires no
   operator intervention because the password is stored in digest
   ("hashed") form in a file at each station. From that point on,
   subsequent accesses of controlled directories proceed normally.
   Use new configuration file parameter 'ac-files-dir' in the [arim]
   section to specify an access-controlled shared files directory. For
   example:
      ac-files-dir = admin
   or
      ac-files-dir = admin/*
   This parameter uses the same syntax as the 'add-files-dir'
   parameter; see the ARIM Help document for details. The directory
   path must be relative to the shared files root directory specified
   by the 'files-dir' parameter. Up to 16 'ac-files-dir' parameters
   may be defined.
   -----
   Note that shared files directories defined by 'add-files-dir'
   parameters in the ARIM configuration file remain public, and that
   the root shared files directory is always accessible to any station
   for file listing, uploads and downloads.
3. Add new command 'passwd'. Use this to create or change a password
   to allow another station to authenticate itself to your station,
   or, vice versa, for use by your station to authenticate itself to
   another station. For example:
      passwd client_call server_call jabber#wocky
   The first parameter is the call sign of the "client" station. This
   is the station whose operator will connect to another station, the
   "server" station and needs the password to authenticate if
   challenged.  The second parameter is the call sign of the TNC at
   the "server" station to which the client station connects. This is
   the call sign set by the 'mycall' parameter in the corresponding
   [tnc] section in the arim.ini configuration file at the server
   station. The third parameter is the password, which may include any
   printable character, and has a maximum length of 32 characters.
   -----
   See the "Note on client/server roles" section above for a
   discussion of the client/server roles and password setup for
   different cases.
   -----
   The password digest file is named "arim-digest" and is located in
   the same directory as the arim.ini configuration file. To protect
   against accidental disclosure of password file contents, any file
   named 'arim-digest', or variations like 'arim-digest.bak', no
   matter where located in the file system, are protected against
   access by a remote station. Avoid easy-to-guess passwords, and
   never include the call signs of the client or server stations in
   the password.  While the base64 encoded Blake2 digest (HA1) may
   look quite random, it contains only as much entropy as the original
   password, so choose passwords well.
4. Add new command 'delpass'. Use this to delete a password entry
   from the password file. For example:
      delpass KA8RYU NW8L-1
   Like the passwd command, the first parameter is the call sign of
   the client station and the second is the call sign of the TNC at
   the server station.
5. Add new command 'rp' to the "List Files" view . Use this to read
   the "arim-digest" password digest file. Each line has three parts,
   in this order: the client call sign, the server call sign, and the
   Blake2 hash of the combination of both call signs and the password.
   For example:
      KA8RYU:NW8L-1:IhUyNUJ+J37BV9/dqyjM4sw3bUyDv8v6rFyy0tPx
   The file is named "arim-digest" and is located in the same
   directory as the arim.ini configuration file. This is useful for
   keeping track of passwords you have stored.
6. Add new ARQ command '/auth'. This can be used to immediately
   authenticate the remote station after you connect.
7. In file listings made with the 'flist' command, access-controlled
   directories are marked with a '!' (bang) character, like this:
      [16:16:34] >> [@]              medical    !DIR
   to indicate that they are accessible only to authenticated stations
   in an ARQ session. Access controlled directories are also marked
   with a '!' in the Shared Files viewer:
      [ 11] admin                      !DIRECTORY Jan 14 02:58 2018
8. Add new indicator '+' to the ARQ status field. If an ARQ session
   is authenticated, then the '+' character is appended to the call
   sign of the remote station.
9. Notes on interoperability with older versions of ARIM:
   * The ARQ mode file upload protocol (/fput command) in version
     1.2 is changed slightly and is NOT compatible with previous
     versions. Otherwise, version 1.2 is interoperable with older
     versions of ARIM in ARQ mode.
   * FEC mode operations are unchanged; version 1.2 is fully
   interoperable with older versions. Note that the contents of access
   controlled directories are never accessible to FEC mode commands
   like 'flist' and 'file'. However, the contents of the root shared
   files directory and additional shared directories declared with the
   'add-files-dir' parameter in the configuration file are always
   accessible.
10. Update man pages, embedded Help and PDF Help file.

Join main@digitalradio.groups.io to automatically receive all group messages.