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 were 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 their 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:
556 Each message is a NUL-terminated UTF string.
557 The server begins by sending a list of
560 pairs it is willing to use.
562 responds with its choice.
564 A second version of this protocol exists (indicated
567 prefix before the list) where the server sends
568 an explicit confirmation with a OK message before
569 the agreed-upon protocol starts.
586 protocol is the protocol used by all
588 The file server runs it over special
594 Other services, such as
601 over the network and then use the session secret to derive an
605 key to encrypt the rest of their communications.
607 Users connect directly to the AS
608 to change their passwords.
619 The client sends a password change ticket request.
628 The server responds with a ticket containing the key
630 encrypted with the client's key
640 The client decrypts the ticket using the old password
641 and then sends back an encrypted password request
644 containing the old password and the new password.
647 is set, the AS also changes
650 the password used for non-Plan 9 authentications.
656 64-byte error message
658 The AS responds with simply
662 followed by a 64-byte error message.
663 .SS "Authentication Database
669 This database maintains ``speaks for'' relationships, i.e.,
670 it lists which users may speak for other users when
672 The attribute types used by the AS are
678 is a client host's ID.
681 pairs in the same entry list which users that host ID
685 means the host ID may speak for all users.
688 means the host ID may not speak for
694 uid=!sys uid=!adm uid=*
699 may speak for any user except
703 This property is used heavily on CPU servers.
704 .SS "Foreign Protocols
705 The AS accepts ticket request
706 messages of types other than
709 authenticate using non-Plan 9 protocols.
710 In these situations, the server communicates
711 directly with the AS.
712 Some protocols must begin without knowing the
713 client's name. They ignore the client name in the
715 All the protocols end
719 message containing a server ticket and authenticator.
723 always have a fixed but context-dependent size.
724 The occasional variable-length OK message starts with a
726 byte and a five-byte space-padded decimal length of the
731 message is expected, a
733 message may be substituted.
764 This protocol allows the use of
765 handheld authenticators such as SecureNet
766 keys and SecureID tokens
783 is a random five-digit decimal number.
784 When using a SecureNet key or
790 is an eight-digit decimal or hexadecimal number
791 that is an encryption of the challenge
792 using the user's DES key.
794 When using a SecureID token,
795 the challenge is ignored.
796 The response is the user's PIN followed by
797 the six-digit number currently displayed
800 queries an external RADIUS server
801 to check the response.
802 Use of a RADIUS server requires an entry in
803 the authentication database. For example:
806 radius=server-name secret=xyzzy
807 uid=howard rid=trickey
808 uid=sape rid=smullender
811 In this example, the secret
813 is the hash key used in talking to the RADIUS server.
816 lines map from Plan 9 user ids to RADIUS ids.
817 Users not listed are assumed to have the
818 same id in both places.
839 hexadecimal MD5 checksum
842 This protocol implements APOP authentication
845 After receiving a ticket request of type
847 the AS generates a random challenge
849 .BI < random @ domain >\fR.
850 The client then replies with a new ticket request
852 followed by the MD5 checksum of
853 the challenge concatenated with the user's secret.
854 If the response is correct, the authentication
855 server sends back a ticket
857 If the response is incorrect, the client may repeat the
858 ticket request/MD5 checksum message to try again.
862 protocol runs identically to the
864 protocol, except that the expected MD5 checksum
865 is the keyed MD5 hash using the user's secret as the key
888 This protocol implements CHAP authentication
893 is eight random bytes.
894 The response is a 16-byte MD5 checksum
895 over the packet id, user's secret, and challenge.
896 The reply packet is defined as
918 This protocol implements Microsoft's MS-CHAP
924 is eight random bytes.
925 The two responses are Microsoft's LM and NT hashes.
926 Only the NT hash may be used to authenticate,
927 as the LM hash is considered too weak.
928 The reply packet is defined as
949 This protocol implements VNC authentication
954 The challenge is 16 random bytes, and the response
955 is a DES ECB encryption of the challenge.
956 The method by which VNC converts the user's
957 secret into a DES key is weak,
958 considering only the first eight bytes of the secret.
961 .TF /lib/ndb/auth.*xxx