3 authsrv, p9any, p9sk1, dp9ik \- authentication protocols
5 This manual page describes
6 the protocols used to authorize connections, confirm the identities
7 of users and machines, and maintain the associated databases.
8 The machine that provides these services is called the
9 .I authentication server
11 The AS may be a stand-alone machine or a general-use machine such as a CPU server.
14 holds for each public machine, such as a CPU server or
15 file server, the name of the authentication server that machine uses.
17 Each machine contains four values important to authentication; a 56-bit DES
18 key, a 128-bit AES key, a 28-byte authentication ID, and a 48-byte authentication
20 The ID is a user name and identifies who is currently responsible for the
21 kernel running on that machine.
22 The domain name identifies the machines across which the ID is valid.
23 Together, the ID and domain name identify the owner of a key.
25 When a terminal boots,
27 prompts for user name and password.
28 The user name becomes the terminal's authentication ID.
29 The password is converted using
33 into a 56-bit DES and 128-bit AES keys and saved in memory.
34 The authentication domain is set to the null string.
37 validates the key with the AS
39 For Internet machines the correct AS to ask is found using
42 When a CPU or file server boots,
44 reads the key, ID, and domain name from
46 This allows servers to reboot without operator intervention.
48 The details of any authentication are mixed with the semantics
49 of the particular service they are authenticating so we describe
50 them one case at a time. The following definitions will be used
55 server's host ID's key
58 client's host ID's key
61 a nonce key created for a ticket
71 an 8-byte random challenge from a client
75 an 8-byte random challenge from a server
83 server's authentication domain name
92 client's desired ID on server
97 client → AS DH public key
100 AS → client DH public key
103 server → AS DH public key
106 AS → server DH public key
109 client's 32-byte random string
112 server's 32-byte random string
115 The parenthesized names are the ones used in the
122 The message type constants
140 as are the encrypted message types
149 When a client and server wish to authenticate to each other,
153 Obtaining tickets from the AS
154 is the client's responsibility.
156 The protocol to obtain a ticket pair is:
179 The two tickets are identical except for their type fields
180 and the keys with which they are encrypted.
181 The client and server can each decrypt one of the tickets,
182 establishing a shared secret
186 tickets can be viewed as a statement by the
188 ``a client possessing the
190 key is allowed to authenticate as
193 The presence of the server challenge
195 in the ticket allows the server to verify the freshness
200 in the tickets to the requested
218 the AS silently generates one-time
219 random keys to use in place of
223 so that clients cannot probe the AS
224 to learn whether a user name is valid.
226 The Plan 9 shared key protocol
228 allows a client and server to authenticate each other.
234 The client starts by sending a random challenge to the server.
244 The server replies with a ticket request giving its
245 id and authentication domain along with its own
261 to the ticket request and obtains a ticket pair
262 from the AS as described above.
263 The client relays the server's ticket along with
269 The authenticator proves to the server that the
272 and is therefore allowed to authenticate as
276 in the authenticator avoids replay attacks.)
282 The server replies with its own authenticator,
283 proving to the client that it also knows
288 The 64-bit shared secret
290 is used as the session secret.
291 .SS "Password authenticated key exchange"
292 Initially, the server and client keys
296 where equivalent to the password derived 56-bit DES keys, which
297 made the encrypted tickets subject to offline dictionary attacks
298 and provided too small a key space against brute force attacks
303 protocol is used to establish new 256-bit random keys with the
308 before each ticket request on the connection.
310 The protocol is based on SPAKE2EE, where a hash of the user's secret
311 is used to encypt the public keys of a Elliptic-Curve Diffie-Hellman
312 key exchange. The user's
314 and 128-bit AES key is hashed and mapped (using Elligator2)
315 into two curve points
321 Both sides generate a random number
323 and make the public keys
328 After the public keys have been exchanged, each side calculates the
330 .IR Z = xa*(YB-PN) = xb*(YA-PM) .
333 is then hashed with the transmitted public keys
335 producing the 256-bit
340 is then used in place of
344 to authenticate and encrypt tickets from the AS using
345 Chacha20/Poly1305 AEAD for the next following
346 request made on the connection.
378 to establish a single server key
398 to establish a single client key
418 protocol is an extended version of
420 that adds the random strings
426 messages for the session key derivation and uses the
427 password authenticated key exchange as described above
428 to derive the ticket encryption keys
436 The client starts by sending a random challenge to the server.
447 The server generates a new public key
453 and authentication domain
455 along with its own random challenge
471 The client generates its own public key
473 and adds it along with
479 request and obtains the public keys
483 from the AS response. At this point, client and AS
484 have completed ther authenticated key exchange and
488 Then the client requests a ticket pair using the same
493 It decrypts his ticket with
495 extracting the shared secret
497 The client relays the server's
499 and ticket along with an
504 The server finishes his authenticated key exchange
509 to decrypt his ticket to extract the shared secret
511 When the decryption of the clients authenticator using
513 is successfull then this proves to the server that the
516 and is therefore allowed to authenticate as
520 is used in the derivation of the session secret.
527 The server replies with its own authenticator,
528 proving to the client that it also knows
530 and contributes its random string
532 for the session secret.
534 The 2048-bit session secret is derived with HKDF-SHA256 hashing the
535 concatenated random strings
537 with the the shared secret key
541 is the standard Plan 9 authentication protocol.
542 It consists of a negotiation to determine a common
543 protocol, followed by the agreed-upon protocol.
545 The negotiation protocol is:
560 Each message is a NUL-terminated UTF string.
561 The server begins by sending a list of
564 pairs it is willing to use.
566 responds with its choice.
567 Requiring the client to wait for the final
569 ensures that the client will not start
570 the chosen protocol until the server is ready.
572 The above is version 2 of the protocol.
575 omitted the first message's
584 protocol is the protocol used by all
586 The file server runs it over special
592 Other services, such as
599 over the network and then use the session secret to derive an
603 key to encrypt the rest of their communications.
605 Users connect directly to the AS
606 to change their passwords.
617 The client sends a password change ticket request.
626 The server responds with a ticket containing the key
628 encrypted with the client's key
638 The client decrypts the ticket using the old password
639 and then sends back an encrypted password request
642 containing the old password and the new password.
645 is set, the AS also changes
648 the password used for non-Plan 9 authentications.
654 64-byte error message
656 The AS responds with simply
660 followed by a 64-byte error message.
661 .SS "Authentication Database
667 This database maintains ``speaks for'' relationships, i.e.,
668 it lists which users may speak for other users when
670 The attribute types used by the AS are
676 is a client host's ID.
679 pairs in the same entry list which users that host ID
683 means the host ID may speak for all users.
686 means the host ID may not speak for
692 uid=!sys uid=!adm uid=*
697 may speak for any user except
701 This property is used heavily on CPU servers.
702 .SS "Foreign Protocols
703 The AS accepts ticket request
704 messages of types other than
707 authenticate using non-Plan 9 protocols.
708 In these situations, the server communicates
709 directly with the AS.
710 Some protocols must begin without knowing the
711 client's name. They ignore the client name in the
713 All the protocols end
717 message containing a server ticket and authenticator.
721 always have a fixed but context-dependent size.
722 The occasional variable-length OK message starts with a
724 byte and a five-byte space-padded decimal length of the
729 message is expected, a
731 message may be substituted.
762 This protocol allows the use of
763 handheld authenticators such as SecureNet
764 keys and SecureID tokens
781 is a random five-digit decimal number.
782 When using a SecureNet key or
788 is an eight-digit decimal or hexadecimal number
789 that is an encryption of the challenge
790 using the user's DES key.
792 When using a SecureID token,
793 the challenge is ignored.
794 The response is the user's PIN followed by
795 the six-digit number currently displayed
798 queries an external RADIUS server
799 to check the response.
800 Use of a RADIUS server requires an entry in
801 the authentication database. For example:
804 radius=server-name secret=xyzzy
805 uid=howard rid=trickey
806 uid=sape rid=smullender
809 In this example, the secret
811 is the hash key used in talking to the RADIUS server.
814 lines map from Plan 9 user ids to RADIUS ids.
815 Users not listed are assumed to have the
816 same id in both places.
837 hexadecimal MD5 checksum
840 This protocol implements APOP authentication
843 After receiving a ticket request of type
845 the AS generates a random challenge
847 .BI < random @ domain >\fR.
848 The client then replies with a new ticket request
850 followed by the MD5 checksum of
851 the challenge concatenated with the user's secret.
852 If the response is correct, the authentication
853 server sends back a ticket
855 If the response is incorrect, the client may repeat the
856 ticket request/MD5 checksum message to try again.
860 protocol runs identically to the
862 protocol, except that the expected MD5 checksum
863 is the keyed MD5 hash using the user's secret as the key
886 This protocol implements CHAP authentication
891 is eight random bytes.
892 The response is a 16-byte MD5 checksum
893 over the packet id, user's secret, and challenge.
894 The reply packet is defined as
916 This protocol implements Microsoft's MS-CHAP
922 is eight random bytes.
923 The two responses are Microsoft's LM and NT hashes.
924 Only the NT hash may be used to authenticate,
925 as the LM hash is considered too weak.
926 The reply packet is defined as
947 This protocol implements VNC authentication
952 The challenge is 16 random bytes, and the response
953 is a DES ECB encryption of the challenge.
954 The method by which VNC converts the user's
955 secret into a DES key is weak,
956 considering only the first eight bytes of the secret.
959 .TF /lib/ndb/auth.*xxx