3 authsrv, p9any, p9sk1, p9sk2 \- 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 three values important to authentication; a 56-bit DES
18 key, a 28-byte authentication ID, and a 48-byte authentication domain name.
19 The ID is a user name and identifies who is currently responsible for the
20 kernel running on that machine.
21 The domain name identifies the machines across which the ID is valid.
22 Together, the ID and domain name identify the owner of a key.
24 When a terminal boots,
26 prompts for user name and password.
27 The user name becomes the terminal's authentication ID.
28 The password is converted using
32 into a 56-bit DES key and saved in memory.
33 The authentication domain is set to the null string.
36 validates the key with the AS
38 For Internet machines the correct AS to ask is found using
41 When a CPU or file server boots,
43 reads the key, ID, and domain name from
45 This allows servers to reboot without operator intervention.
47 The details of any authentication are mixed with the semantics
48 of the particular service they are authenticating so we describe
49 them one case at a time. The following definitions will be used
54 server's host ID's key
57 client's host ID's key
60 a nonce key created for a ticket
70 an 8-byte random challenge from a client
74 an 8-byte random challenge from a server
82 server's authentication domain name
91 client's desired ID on server
96 The parenthesized names are the ones used in the
103 The message type constants
120 as are the encrypted message types
129 When a client and server wish to authenticate to each other,
133 Obtaining tickets from the AS
134 is the client's responsibility.
136 The protocol to obtain a ticket pair is:
160 The two tickets are identical except for their type fields
161 and the keys with which they are encrypted.
162 The client and server can each decrypt one of the tickets,
163 establishing a shared secret
167 tickets can be viewed as a statement by the
169 ``a client possessing the
171 key is allowed to authenticate as
174 The presence of the server challenge
176 in the ticket allows the server to verify the freshness
181 in the tickets to the requested
199 the AS silently generates one-time
200 random keys to use in place of
204 so that clients cannot probe the AS
205 to learn whether a user name is valid.
207 The Plan 9 shared key protocol
209 allows a client and server to authenticate each other.
215 The client starts by sending a random challenge to the server.
225 The server replies with a ticket request giving its
226 id and authentication domain along with its own
242 to the ticket request and obtains a ticket pair
243 from the AS as described above.
244 The client relays the server's ticket along with
250 The authenticator proves to the server that the
253 and is therefore allowed to authenticate as
257 in the authenticator avoids replay attacks.)
263 The server replies with its own authenticator,
264 proving to the client that it also knows
271 is an older variant of
273 used only when connecting to pre-9P2000 remote
275 It omits the first message and last
276 messages and therefore does not
277 authenticate the server to the client.
280 is the standard Plan 9 authentication protocol.
281 It consists of a negotiation to determine a common
282 protocol, followed by the agreed-upon protocol.
284 The negotiation protocol is:
301 Each message is a NUL-terminated UTF string.
302 The server begins by sending a list of
305 pairs it is willing to use.
307 responds with its choice.
308 Requiring the client to wait for the final
310 ensures that the client will not start
311 the chosen protocol until the server is ready.
313 The above is version 2 of the protocol.
316 omitted the first message's
325 protocol is the protocol used by all
327 The file server runs it over special
333 Other services, such as
339 over the network and then
344 key to encrypt the rest of their communications.
346 Users connect directly to the AS
347 to change their passwords.
358 The client sends a password change ticket request.
367 The server responds with a ticket containing the key
369 encrypted with the client's key
379 The client decrypts the ticket using the old password
380 and then sends back an encrypted password request
383 containing the old password and the new password.
386 is set, the AS also changes
389 the password used for non-Plan 9 authentications.
395 64-byte error message
397 The AS responds with simply
401 followed by a 64-byte error message.
402 .SS "Authentication Database
408 This database maintains ``speaks for'' relationships, i.e.,
409 it lists which users may speak for other users when
411 The attribute types used by the AS are
417 is a client host's ID.
420 pairs in the same entry list which users that host ID
424 means the host ID may speak for all users.
427 means the host ID may not speak for
433 uid=!sys uid=!adm uid=*
438 may speak for any user except
442 This property is used heavily on CPU servers.
443 .SS "Foreign Protocols
444 The AS accepts ticket request
445 messages of types other than
448 authenticate using non-Plan 9 protocols.
449 In these situations, the server communicates
450 directly with the AS.
451 Some protocols must begin without knowing the
452 client's name. They ignore the client name in the
454 All the protocols end
458 message containing a server ticket and authenticator.
462 always have a fixed but context-dependent size.
463 The occasional variable-length OK message starts with a
465 byte and a five-byte space-padded decimal length of the
470 message is expected, a
472 message may be substituted.
508 This protocol allows the use of
509 handheld authenticators such as SecureNet
510 keys and SecureID tokens
527 is a random five-digit decimal number.
528 When using a SecureNet key or
534 is an eight-digit decimal or hexadecimal number
535 that is an encryption of the challenge
536 using the user's DES key.
538 When using a SecureID token,
539 the challenge is ignored.
540 The response is the user's PIN followed by
541 the six-digit number currently displayed
544 queries an external RADIUS server
545 to check the response.
546 Use of a RADIUS server requires an entry in
547 the authentication database. For example:
550 radius=server-name secret=xyzzy
551 uid=howard rid=trickey
552 uid=sape rid=smullender
555 In this example, the secret
557 is the hash key used in talking to the RADIUS server.
560 lines map from Plan 9 user ids to RADIUS ids.
561 Users not listed are assumed to have the
562 same id in both places.
585 hexadecimal MD5 checksum
588 This protocol implements APOP authentication
591 After receiving a ticket request of type
593 the AS generates a random challenge
595 .BI < random @ domain >\fR.
596 The client then replies with a new ticket request
598 followed by the MD5 checksum of
599 the challenge concatenated with the user's secret.
600 If the response is correct, the authentication
601 server sends back a ticket
603 If the response is incorrect, the client may repeat the
604 ticket request/MD5 checksum message to try again.
608 protocol runs identically to the
610 protocol, except that the expected MD5 checksum
611 is the keyed MD5 hash using the user's secret as the key
636 This protocol implements CHAP authentication
641 is eight random bytes.
642 The response is a 16-byte MD5 checksum
643 over the packet id, user's secret, and challenge.
644 The reply packet is defined as
668 This protocol implements Microsoft's MS-CHAP
674 is eight random bytes.
675 The two responses are Microsofts LM and NT hashes.
676 Only the NT hash may be used to authenticate,
677 as the LM hash is considered too weak.
678 The reply packet is defined as
701 This protocol implements VNC authentication
706 The challenge is 16 random bytes, and the response
707 is a DES ECB encryption of the challenge.
708 The method by which VNC converts the user's
709 secret into a DES key is weak,
710 considering only the first eight bytes of the secret.
713 .TF /lib/ndb/auth.*xxx
projects / plan9front.git / blob