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
287 .SS "Password authenticated key exchange"
288 Initially, the server and client keys
292 where equivalent to the password derived 56-bit DES keys, which
293 made the encrypted tickets subject to offline dictionary attacks
294 and provided too small a key space against brute force attacks
299 protocol is used to establish new 256-bit random keys with the
304 before each ticket request on the connection.
306 The protocol is based on SPAKE2EE, where a hash of the user's secret
307 is used to encypt the public keys of a Elliptic-Curve Diffie-Hellman
308 key exchange. The user's
310 and 128-bit AES key is hashed and mapped (using Elligator2)
311 into two curve points
317 Both sides generate a random number
319 and make the public keys
324 After the public keys have been exchanged, each side calculates the
326 .IR Z = xa*(YB-PN) = xb*(YA-PM) .
329 is then hashed with the transmitted public keys
331 producing the 256-bit
336 is then used in place of
340 to authenticate and encrypt tickets from the AS using
341 Chacha20/Poly1305 AEAD for the next following
342 request made on the connection.
374 to establish a single server key
394 to establish a single client key
414 protocol is an extended version of
416 that adds the random strings
422 messages for the session key derivation and uses the
423 password authenticated key exchange as described above
424 to derive the ticket encryption keys
432 The client starts by sending a random challenge to the server.
443 The server generates a new public key
449 and authentication domain
451 along with its own random challenge
467 The client generates its own public key
469 and adds it along with
475 request and obtains the public keys
479 from the AS response. At this point, client and AS
480 have completed ther authenticated key exchange and
484 Then the client requests a ticket pair using the same
489 It decrypts his ticket with
491 extracting the shared secret
493 The client relays the server's
495 and ticket along with an
500 The server finishes his authenticated key exchange
505 to decrypt his ticket to extract the shared secret
507 When the decryption of the clients authenticator using
509 is successfull then this proves to the server that the
512 and is therefore allowed to authenticate as
516 is used in the derivation of the session secret.
523 The server replies with its own authenticator,
524 proving to the client that it also knows
526 and contributes its random string
528 for the session secret.
530 The 2048-bit session secret is derived with a PRF hashing the
531 concatenated random strings
533 with the the shared secret key
537 is the standard Plan 9 authentication protocol.
538 It consists of a negotiation to determine a common
539 protocol, followed by the agreed-upon protocol.
541 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.
563 Requiring the client to wait for the final
565 ensures that the client will not start
566 the chosen protocol until the server is ready.
568 The above is version 2 of the protocol.
571 omitted the first message's
580 protocol is the protocol used by all
582 The file server runs it over special
588 Other services, such as
594 over the network and then
599 key to encrypt the rest of their communications.
601 Users connect directly to the AS
602 to change their passwords.
613 The client sends a password change ticket request.
622 The server responds with a ticket containing the key
624 encrypted with the client's key
634 The client decrypts the ticket using the old password
635 and then sends back an encrypted password request
638 containing the old password and the new password.
641 is set, the AS also changes
644 the password used for non-Plan 9 authentications.
650 64-byte error message
652 The AS responds with simply
656 followed by a 64-byte error message.
657 .SS "Authentication Database
663 This database maintains ``speaks for'' relationships, i.e.,
664 it lists which users may speak for other users when
666 The attribute types used by the AS are
672 is a client host's ID.
675 pairs in the same entry list which users that host ID
679 means the host ID may speak for all users.
682 means the host ID may not speak for
688 uid=!sys uid=!adm uid=*
693 may speak for any user except
697 This property is used heavily on CPU servers.
698 .SS "Foreign Protocols
699 The AS accepts ticket request
700 messages of types other than
703 authenticate using non-Plan 9 protocols.
704 In these situations, the server communicates
705 directly with the AS.
706 Some protocols must begin without knowing the
707 client's name. They ignore the client name in the
709 All the protocols end
713 message containing a server ticket and authenticator.
717 always have a fixed but context-dependent size.
718 The occasional variable-length OK message starts with a
720 byte and a five-byte space-padded decimal length of the
725 message is expected, a
727 message may be substituted.
758 This protocol allows the use of
759 handheld authenticators such as SecureNet
760 keys and SecureID tokens
777 is a random five-digit decimal number.
778 When using a SecureNet key or
784 is an eight-digit decimal or hexadecimal number
785 that is an encryption of the challenge
786 using the user's DES key.
788 When using a SecureID token,
789 the challenge is ignored.
790 The response is the user's PIN followed by
791 the six-digit number currently displayed
794 queries an external RADIUS server
795 to check the response.
796 Use of a RADIUS server requires an entry in
797 the authentication database. For example:
800 radius=server-name secret=xyzzy
801 uid=howard rid=trickey
802 uid=sape rid=smullender
805 In this example, the secret
807 is the hash key used in talking to the RADIUS server.
810 lines map from Plan 9 user ids to RADIUS ids.
811 Users not listed are assumed to have the
812 same id in both places.
833 hexadecimal MD5 checksum
836 This protocol implements APOP authentication
839 After receiving a ticket request of type
841 the AS generates a random challenge
843 .BI < random @ domain >\fR.
844 The client then replies with a new ticket request
846 followed by the MD5 checksum of
847 the challenge concatenated with the user's secret.
848 If the response is correct, the authentication
849 server sends back a ticket
851 If the response is incorrect, the client may repeat the
852 ticket request/MD5 checksum message to try again.
856 protocol runs identically to the
858 protocol, except that the expected MD5 checksum
859 is the keyed MD5 hash using the user's secret as the key
882 This protocol implements CHAP authentication
887 is eight random bytes.
888 The response is a 16-byte MD5 checksum
889 over the packet id, user's secret, and challenge.
890 The reply packet is defined as
912 This protocol implements Microsoft's MS-CHAP
918 is eight random bytes.
919 The two responses are Microsoft's LM and NT hashes.
920 Only the NT hash may be used to authenticate,
921 as the LM hash is considered too weak.
922 The reply packet is defined as
943 This protocol implements VNC authentication
948 The challenge is 16 random bytes, and the response
949 is a DES ECB encryption of the challenge.
950 The method by which VNC converts the user's
951 secret into a DES key is weak,
952 considering only the first eight bytes of the secret.
955 .TF /lib/ndb/auth.*xxx