Clarify arbiter authentication

source/core/replica-set-arbiter.txt

@@ -17,18 +17,15 @@ Replica Set Arbiter
 
 An arbiter does **not** have a copy of data set and **cannot** become
 a primary. Replica sets may have arbiters to add a vote in
-:ref:`elections of for primary <replica-set-elections>`. Arbiters
+:ref:`elections for primary <replica-set-elections>`. Arbiters
 *always* have exactly ``1`` election vote, and thus
 allow replica sets to have an uneven number of voting members without the
 overhead of an additional member that replicates data.
 
 .. important:: Do not run an arbiter on systems that also host the
    primary or the secondary members of the replica set.
 
-Only add an arbiter to sets with even numbers of voting members. If you
-add an arbiter to a set with an odd number of voting members, the set
-may suffer from tied :term:`elections <election>`. To add an arbiter,
-see :doc:`/tutorial/add-replica-set-arbiter`.
+To add an arbiter, see :doc:`/tutorial/add-replica-set-arbiter`.
 
 .. include:: /includes/extracts/arbiters-and-pvs-with-reference.rst
 
@@ -54,12 +51,14 @@ Authentication
 ~~~~~~~~~~~~~~
 
 When running with :setting:`~security.authorization`, arbiters exchange credentials with
-other members of the set to authenticate. MongoDB encrypts the
+other members of the set to authenticate via :setting:`keyfiles <keyfile>`. MongoDB encrypts the
 authentication process. The MongoDB authentication exchange is
 cryptographically secure.
 
-Arbiters use :setting:`keyfiles <keyfile>` to authenticate to the
-replica set.
+Because arbiters do not store data, they do not possess the internal table of user and role mappings
+used for authentication.  Thus, the only way to log on to an arbiter with authorization active is to
+use the localhost exception.
+
 
 Communication
 ~~~~~~~~~~~~~