1 .HTML "Security in Plan 9
13 Eric Grosse, Bell Labs
17 Dave Presotto, Avaya Labs and Bell Labs
19 Sean Quinlan, Bell Labs
21 .CW {rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com
23 The security architecture of the Plan 9™
24 operating system has recently been redesigned
25 to address some technical shortcomings.
26 This redesign provided an opportunity also to make the system more
27 convenient to use securely.
28 Plan 9 has thus improved in two ways not usually seen together:
29 it has become more secure
33 The central component of the new architecture is a per-user
34 self-contained agent called
38 copy of the user's keys and negotiates authentication protocols, on
39 behalf of the user, with secure services around the network.
40 Concentrating security code in a single program offers several
41 advantages including: ease of update or repair to broken security
42 software and protocols; the ability to run secure services at a lower
43 privilege level; uniform management of keys for all services; and an
44 opportunity to provide single sign on, even to unchanged legacy
47 has an unusual architecture: it is implemented
48 as a Plan 9 file server.
50 Appeared, in a slightly different form, in
52 Proc. of the 2002 Usenix Security Symposium,
60 Secure computing systems face two challenges:
61 first, they must employ sophisticated technology that is difficult to design
62 and prove correct; and second,
63 they must be easy for regular people to use.
64 The question of ease of use is sometimes neglected, but it is essential:
65 weak but easy-to-use security can be more effective than strong but
66 difficult-to-use security if it is more likely to be used.
67 People lock their front doors when they leave the house, knowing
68 full well that a burglar is capable of picking the lock (or avoiding
69 the door altogether); yet few would accept the cost and
70 awkwardness of a bank vault door on the
71 house even though that might reduce the probability of a robbery.
72 A related point is that users need a clear model of how the security
73 operates (if not how it actually provides security) in order to use it
74 well; for example, the clarity of a lock icon on a web browser
75 is offset by the confusing and typically insecure
76 steps for installing X.509 certificates.
78 The security architecture of the Plan 9
81 has recently been redesigned to make it both more secure
86 first, the business of authenticating users and services;
87 second, the safe handling, deployment, and use of keys
88 and other secret information; and
89 third, the use of encryption and integrity checks
90 to safeguard communications
93 The old security architecture of Plan 9
94 had several engineering problems in common with other operating systems.
95 First, it had an inadequate notion of security domain.
96 Once a user provided a password to connect to a local file store,
97 the system required that the same password be used to access all the other file
99 That is, the system treated all network services as
100 belonging to the same security domain.
102 Second, the algorithms and protocols used in authentication,
103 by nature tricky and difficult to get right, were compiled into the
104 various applications, kernel modules, and file servers.
105 Changes and fixes to a security protocol
106 required that all components using that protocol needed to be recompiled,
107 or at least relinked, and restarted.
109 Third, the file transport protocol, 9P
111 that forms the core of
112 the Plan 9 system, had its authentication protocol embedded in its design.
113 This meant that fixing or changing the authentication used by 9P
114 required deep changes to the system.
115 If someone were to find a way to break the protocol, the system would
116 be wide open and very hard to fix.
118 These and a number of lesser problems, combined with a desire
119 for more widespread use of encryption in the system, spurred us to
120 rethink the entire security architecture of Plan 9.
122 The centerpiece of the new architecture is an agent,
125 that handles the user's keys and negotiates all security
126 interactions with system services and applications.
127 Like a trusted assistant with a copy of the owner's keys,
129 does all the negotiation for security and authentication.
130 Programs no longer need to be compiled with cryptographic
131 code; instead they communicate with
134 that represent distinct entities in the cryptographic exchange,
135 such as a user and server of a secure service.
136 If a security protocol needs to be added, deleted, or modified,
139 needs to be updated for all system services
145 secure services in the system to move
146 user authentication code into
148 made authentication a separable component of the file server protocol;
149 deployed new security protocols;
150 designed a secure file store,
153 to protect our keys but make them easy to get when they are needed;
154 designed a new kernel module to support transparent use of
155 Transport Layer Security (TLS)
157 and began using encryption for all communications within the system.
158 The overall architecture is illustrated in Figure 1a.
167 Sec: box "Secstore" wid 1.3i ht .5i
170 Term0: box invis ht .1i with .e at Sec.e + (-1.1i, -.5i)
171 Term: box wid 1.1i ht 1i with .nw at Term0.ne
172 Termlab: "\s-2Terminal\s+2" at Term.s + (0, -.15i)
173 FT: ellipse "$ F sub T#" wid .40i ht .30i with .ne at Term.ne + (-.1i, -.1i)
174 PT: ellipse "$ P sub T#" wid .6i ht .45i with .sw at Term.sw + (.2i, .2i)
177 Cpu0: box invis ht .1i with .w at Term0.w + (3i, 0)
178 Cpu: box wid 1.1i ht 1i with .nw at Cpu0.ne
179 Cpulab: "\s-2CPU Server\s+2" at Cpu.s + (0, -.15i)
180 FC: ellipse "$ F sub C#" wid .40 ht .30i with .nw at Cpu.nw + (.1i, -.1i)
181 PC: ellipse "$ P sub C#" wid .6i ht .45i with .se at Cpu.se + (-.2i, .2i)
183 # Authentication Server
184 Auth: box dashed "Auth Server" wid 1.3i ht .5i with .e at Sec.e + (0, -2.3i)
187 File0: box invis ht .1i with .w at Cpu0.w + (0, -1.5i)
188 File: box wid 1.1i ht 1i with .nw at File0.ne
189 Filelab: "\s-2File Server\s+2" at File.s + (0, -.15i)
190 FF: ellipse "$ F sub F#" wid .40i ht .30i with .nw at File.nw + (.1i, -.1i)
191 PF: ellipse "$ P sub F#" wid .6i ht .45i with .se at File.se + (-.2i, .2i)
194 line from PT.e + (0, +0.05i) to PC.w + (0, +0.05i)
195 spline from PT.e + (0, -0.05i) right 1i then down 1.5i right .5i then right to PF.w + (0, -0.05i)
196 spline from PC.w + (0, -0.05i) left 1.1i then down 1.4i then right to PF.w + (0, 0.05i)
197 line <-> from FC.se to PC.nw
198 line <-> from FT.sw to PT.ne
199 line <-> from FF.se to PF.nw
200 spline <-> from Sec.e right .5i then down .655i then left to FT.e
201 #spline from Auth.e + (0, 0.05i) right .5i then up 1i then to FT.se
202 #spline from Auth.e + (0, 0.00i) right .7i then up 1i then to FC.sw
203 #spline from Auth.e + (0, -0.05i) right .5i then to FF.w
208 Figure 1a. Components of the security architecture.
209 Each box is a (typically) separate machine; each ellipse a process.
210 The ellipses labeled $F sub X#
213 processes; those labeled
215 are the pieces and proxies of a distributed program.
216 The authentication server is one of several repositories for users' security information
219 processes consult as required.
221 is a shared resource for storing private information such as keys;
223 consults it for the user during bootstrap.
231 Secure protocols and algorithms are well understood
232 and are usually not the weakest link in a system's security.
233 In practice, most security problems arise from buggy servers,
234 confusing software, or administrative oversights.
235 It is these practical problems that we are addressing.
236 Although this paper describes the algorithms and protocols we are using,
237 they are included mainly for concreteness.
238 Our main intent is to present a simple security architecture built
239 upon a small trusted code base that is easy to verify (whether by manual or
240 automatic means), easy to understand, and easy to use.
242 Although it is a subjective assessment,
243 we believe we have achieved our goal of ease of use.
244 That we have achieved
245 our goal of improved security is supported by our plan to
246 move our currently private computing environment onto the Internet
247 outside the corporate firewall.
248 The rest of this paper explains the architecture and how it is used,
249 to explain why a system that is easy to use securely is also safe
250 enough to run in the open network.
252 An Agent for Security
254 One of the primary reasons for the redesign of the Plan 9
255 security infrastructure was to remove the authentication
256 method both from the applications and from the kernel.
258 is large and intricate, so it should
259 be packaged as a separate component that can be repaired or
260 modified without altering or even relinking applications
261 and services that depend on it.
262 If a security protocol is broken, it should be trivial to repair,
263 disable, or replace it on the fly.
264 Similarly, it should be possible for multiple programs to use
265 a common security protocol without embedding it in each program.
267 Some systems use dynamically linked libraries (DLLs) to address these configuration issues.
268 The problem with this approach is that it leaves
269 security code in the same address space as the program using it.
270 The interactions between the program and the DLL
271 can therefore accidentally or deliberately violate the interface,
273 Also, a program using a library to implement secure services
274 must run at a privilege level necessary to provide the service;
275 separating the security to a different program makes it possible
276 to run the services at a weaker privilege level, isolating the
277 privileged code to a single, more trustworthy component.
279 Following the lead of the SSH agent
282 an agent process responsible
283 for holding and using the user's keys.
284 The agent program is called
286 because of its similarity to the proverbial servant with the
287 power to act on behalf of his master because he holds the
288 keys to all the master's possessions. It is essential that
290 keep the keys secret and use them only in the owner's interest.
291 Later we'll discuss some changes to the kernel to reduce the possibility of
293 leaking information inadvertently.
296 is implemented, like most Plan 9 services, as a file server.
297 It is conventionally mounted upon the directory
299 and the files it serves there are analogous to virtual devices that provide access to,
300 and control of, the services of the
302 The next few sections describe the design of
304 and how it operates with the other pieces of Plan 9 to provide
309 To make the discussions that follow more concrete,
310 we begin with a couple of examples showing how the
311 Plan 9 security architecture appears to the user.
312 These examples both involve a user
314 logging in after booting a local machine.
315 The user may or may not have a secure store in which
316 all his keys are kept.
319 will prompt him for the password to the secure store
320 and obtain keys from it, prompting only when a key
321 isn't found in the store.
324 must prompt for each key.
326 In the typescripts, \f6\s9\en\s0\fP
327 represents a literal newline
328 character typed to force a default response.
329 User input is in italics, and
330 long lines are folded and indented to fit.
332 This first example shows a user logging in without
333 help from the secure store.
336 prompts for a user name that the local kernel
339 user[none]: \f6\s9gre\s0\fP
341 (Default responses appear in square brackets.)
342 The kernel then starts accessing local resources
343 and requests, through
345 a user/password pair to do so:
347 !Adding key: dom=cs.bell-labs.com
349 user[gre]: \f6\s9\en\s0\fP
352 Now the user is logged in to the local system, and
353 the mail client starts up:
355 !Adding key: proto=apop
356 server=plan9.bell-labs.com
357 user[gre]: \f6\s9\en\s0\fP
361 is doing all the prompting and the applications
362 being started are not even touching the keys.
363 Note that it's always clear which key is being requested.
365 Now consider the same login sequence, but in the case where
367 has a secure store account:
369 user[none]: \f6\s9gre\s0\fP
370 secstore password: \f6*********\fP
371 STA PIN+SecurID: \f6*********\fP
377 unless an attempt is made to contact
378 a system for which no key is kept in the secure store.
382 Each computer running Plan 9 has one user id that owns all the
383 resources on that system \(em the scheduler, local disks,
384 network interfaces, etc.
387 is the closest analogue in Plan 9 to a Unix
389 account (although it is far weaker;
390 rather than having special powers, as its name implies the host owner
391 is just a regular user that happens to own the
392 resources of the local machine).
393 On a single-user system, which we call a terminal,
394 the host owner is the id of the terminal's user.
395 Shared servers such as CPU servers normally have a pseudo-user
396 that initially owns all resources.
397 At boot time, the Plan 9 kernel starts a
399 executing as, and therefore with the privileges of,
403 the same user as the process which created them.
404 When a process must take on the identity of a new user,
405 such as to provide a login shell
406 on a shared CPU server,
407 it does so by proving to the host owner's
411 This is done by running an
412 authentication protocol with
415 prove that the process has access to secret information
416 which only the new user should possess.
417 For example, consider the setup in Figure 1a.
418 If a user on the terminal
419 wants to log in to the CPU server using the
433 Neither $P sub C# nor $P sub T#
434 knows the details of the authentication.
436 do need to be able to shuttle messages back and
437 forth between the two
440 a generic function easily performed without
441 knowing, or being able to extract, secrets in
444 will make a network connection to $P sub C#.
448 will then relay messages between
451 owned by the user, $F sub T#,
452 and the one owned by the CPU server, $F sub C#,
453 until mutual authentication has been established.
455 sections describe the RPC between
458 applications and the library functions to support proxy operations.
460 The kernel always uses a single local instance of
464 its authentication purposes, but
465 a regular user may start other
470 representing the user need not be
471 running on the same machine as its client.
472 For instance, it is easy for a user on a CPU server,
473 through standard Plan 9 operations,
476 in the user's private file name space on the server
477 with a connection to the
479 running on the terminal.
480 (The usual file system permissions prevent interlopers
481 from doing so maliciously.)
482 This permits secure operations on the CPU server to be
483 transparently validated by the user's own
486 secrets need never leave the user's terminal.
490 same with special SSH protocol messages, but
491 an advantage to making our agent a file system
492 is that we need no new mechanism to access our remote
493 agent; remote file access is sufficient.
497 each protocol is implemented as a state
498 machine with a generic interface, so protocols are in
499 essence pluggable modules, easy to add, modify, or drop.
500 Writing a message to and reading a message from
502 each require a separate RPC and result in
503 a single state transition.
506 always runs to completion on every RPC and never blocks
507 waiting for input during any authentication.
508 Moreover, the number of simultaneous
509 authentications is limited only by the amount of memory we're
510 willing to dedicate to representing the state machines.
512 Authentication protocols are implemented only
515 but adding and removing
516 protocols does require relinking the binary, so
518 processes (but no others)
519 need to be restarted in order to take advantage of
520 new or repaired protocols.
522 At the time of writing,
524 contains authentication
525 modules for the Plan 9 shared key protocol (p9sk1),
526 SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP,
527 Microsoft PPP's MSCHAP, and VNC's challenge/response.
531 A capability system, managed by the kernel, is used to empower
533 to grant permission to another process to change its user id.
536 implements two files,
542 can be opened only by the host owner, and only once.
544 opens this file immediately after booting.
548 creates a string of the form
549 .I userid1\f(CW@\fPuserid2\f(CW@\fPrandom-string ,
550 uses SHA1 HMAC to hash
551 .I userid1\f(CW@\fPuserid2
554 and writes that hash to
557 then passes the original string to another
558 process on the same machine, running
564 The kernel hashes the string and looks for
565 a matching hash in its list.
567 the writing process's user id changes from
571 Once used, or if a timeout expires,
572 the capability is discarded by the kernel.
574 The capabilities are local to the machine on which they are created.
577 running on one machine cannot pass capabilities
578 to processes on another and expect them to work.
584 to mean not only a secret, but also a description of the
585 context in which that secret is to be used: the protocol,
586 server, user, etc. to which it applies.
588 a key is a combination of secret and descriptive information
589 used to authenticate the identities of parties
590 transmitting or receiving information.
592 in any authentication depends both on the protocol and on
593 parameters passed by the program requesting the authentication.
595 Taking a tip from SDSI
597 which represents security information as textual S-expressions,
598 keys in Plan 9 are represented as plain UTF-8 text.
600 understood and manipulated by users.
602 a binary or other cryptic format
603 can actually reduce overall security.
604 Binary formats are difficult for users to examine and can only be
605 cracked by special tools, themselves poorly understood by most users.
606 For example, very few people know or understand what's inside
607 their X.509 certificates.
608 Most don't even know where in the system to
610 Therefore, they have no idea what they are trusting, and why, and
611 are powerless to change their trust relationships.
612 Textual, centrally stored and managed keys are easier to use and safer.
614 Plan 9 has historically represented databases as attribute/value pairs,
615 since they are a good foundation for selection and projection operations.
618 the keys in the format
619 .I attribute\f(CW=\fPvalue ,
622 is an identifier, possibly with a single-character prefix, and
624 is an arbitrary quoted string.
625 The pairs themselves are separated by white space.
626 For example, a Plan 9 key and an APOP key
627 might be represented like this:
629 dom=bell-labs.com proto=p9sk1 user=gre
630 !password='don''t tell'
631 proto=apop server=x.y.com user=gre
632 !password='open sesame'
634 If a value is empty or contains white space or single quotes, it must be quoted;
635 quotes are represented by doubled single quotes.
636 Attributes that begin with an exclamation mark
641 will never let a secret value escape its address space
642 and will suppress keyboard echo when asking the user to type one.
644 A program requesting authentication selects a key
647 a list of elements to be matched by the key.
648 Each element in the list is either an
649 .I attribute\f(CW=\fPvalue
650 pair, which is satisfied by keys with
652 or an attribute followed by a question mark,
654 which is satisfied by keys with some pair specifying
656 A key matches a query if every element in the list
658 For instance, to select the APOP key in the previous example,
659 an APOP client process might specify the query
661 server=x.y.com proto=apop
665 APOP module would add the requirements of
670 attributes, forming the query
672 server=x.y.com proto=apop user? !password?
674 when searching for an appropriate key.
677 modules expect keys to have some well-known attributes.
680 attribute specifies the protocol module
681 responsible for using a particular key,
682 and protocol modules may expect other well-known attributes
683 (many expect keys to have
685 attributes, for example).
686 Additional attributes can be used as comments or for
687 further discrimination without intervention by
689 for example, the APOP and IMAP mail clients conventionally
692 attribute to select an appropriate key for authentication.
695 keys in Plan 9 have no nested structure. This design
696 keeps the representation simple and straightforward.
697 If necessary, we could add a nested attribute
698 or, in the manner of relational databases, an attribute that
699 selects another tuple, but so far the simple design has been sufficient.
701 A simple common structure for all keys makes them easy for users
703 but the set of attributes and their interpretation is still
704 protocol-specific and can be subtle.
706 need to consult a manual to understand all details.
712 are self-explanatory and our short experience
713 has not uncovered any particular difficulty in handling keys.
715 will likely get messier, however,
716 when we grapple with public
717 keys and their myriad components.
721 Secrets must be prevented from escaping
723 There are a number of ways they could leak:
724 another process might be able to debug the agent process, the
725 agent might swap out to disk, or the process might willingly
727 The last is the easiest to avoid:
728 secret information in a key is marked
732 prints keys or queries for new
733 ones, it is careful to avoid displaying secret information.
734 (The only exception to this is the
735 ``plaintext password'' protocol, which consists
736 of sending the values of the
741 Only keys tagged with
743 can have their passwords disclosed by this mechanism.)
745 Preventing the first two forms of leakage
746 requires help from the kernel.
747 In Plan 9, every process is
748 represented by a directory in the
751 Using the files in this directory,
752 other processes could (with appropriate access permission) examine
754 memory and registers.
756 is protected from processes of other users
757 by the default access bits of its
760 However, we'd also like to protect the
761 agent from other processes owned by the same user,
762 both to avoid honest mistakes and to prevent
763 an unattended terminal being
764 exploited to discover secret passwords.
765 To do this, we added a control message to
774 .CW /proc/\f2pid\fP/ctl
775 file, no process can access
780 (Plan 9 has no other mechanism, such as
782 for accessing a process's memory.)
784 Similarly, the agent's address space should not be
785 swapped out, to prevent discovering unencrypted
786 keys on the swapping media.
791 prevents this scenario.
798 User-level file servers such as
800 which interprets FAT file systems,
803 to keep their buffer caches from being
806 Despite our precautions, attackers might still
807 find a way to gain access to a process running as the host
809 Although they could not directly
810 access the keys, attackers could use the local
812 to perform authentications for them.
814 of some keys, for example those locking bank
815 accounts, we want a way to disable or at least
817 That is the role of the
820 Whenever a key with a
822 attribute is accessed, the local user must
823 confirm use of the key via a local GUI.
824 The next section describes the actual mechanism.
826 We have not addressed leaks possible as a result of
827 someone rebooting or resetting a machine running
829 For example, someone could reset a machine
830 and reboot it with a debugger instead of a kernel,
831 allowing them to examine the contents of memory
832 and find keys. We have not found a satisfactory
833 solution to this problem.
835 Factotum transactions
837 External programs manage
840 through its file interface,
846 .CW /mnt/factotum/ctl
848 Both commands take a list of attributes as an argument.
850 creates a key with the given attributes, replacing any
851 extant key with an identical set of public attributes.
853 deletes all keys that match the given set of attributes.
856 file returns a list of keys, one per line, displaying only public attributes.
857 The following example illustrates these interactions.
861 -lrw------- gre gre 0 Jan 30 22:17 confirm
862 --rw------- gre gre 0 Jan 30 22:17 ctl
863 -lr-------- gre gre 0 Jan 30 22:17 log
864 -lrw------- gre gre 0 Jan 30 22:17 needkey
865 --r--r--r-- gre gre 0 Jan 30 22:17 proto
866 --rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
868 key dom=bell-labs.com proto=p9sk1 user=gre
869 !password='don''t tell'
870 key proto=apop server=x.y.com user=gre
874 key dom=bell-labs.com proto=p9sk1 user=gre
875 key proto=apop server=x.y.com user=gre
876 % echo 'delkey proto=apop' >ctl
878 key dom=bell-labs.com proto=p9sk1 user=gre
883 bit set can be opened by only one process at a time.)
885 The heart of the interface is the
888 Programs authenticate with
890 by writing a request to the
893 and reading back the reply; this sequence is called an RPC
895 Requests and replies have the same format:
896 a textual verb possibly followed by arguments,
897 which may be textual or binary.
898 The most common reply verb is
901 An RPC session begins with a
903 transaction; the argument is a key query as described
905 Once started, an RPC conversation usually consists of
911 If the conversation is successful, an
913 transaction will return information about
914 the identities learned during the transaction.
917 transaction returns a list of attributes for the current
918 conversation; the list includes any attributes given in
921 query as well as any public attributes from keys being used.
925 file in action, consider a mail client
926 connecting to a mail server and authenticating using
927 the POP3 protocol's APOP challenge-response command.
928 There are four programs involved: the mail client $P sub C#, the client
930 $F sub C#, the mail server $P sub S#, and the server
933 All authentication computations are handled by the
936 The mail programs' role is just to relay messages.
938 At startup, the mail server at
940 begins an APOP conversation
943 to obtain the banner greeting, which
944 includes a challenge:
946 $P sub S -> F sub S#: start proto=apop role=server
947 $F sub S -> P sub S#: ok
948 $P sub S -> F sub S#: read
949 $F sub S -> P sub S#: ok +OK POP3 \f2challenge\fP
951 Having obtained the challenge, the server greets the client:
953 $P sub S -> P sub C#: +OK POP3 \f2challenge\fP
955 The client then uses an APOP conversation with its
957 to obtain a response:
959 $P sub C -> F sub C#: start proto=apop role=client
961 $F sub C -> P sub C#: ok
962 $P sub C -> F sub C#: write +OK POP3 \f2challenge\fP
963 $F sub C -> P sub C#: ok
964 $P sub C -> F sub C#: read
965 $F sub C -> P sub C#: ok APOP gre \f2response\fP
972 attribute, and the APOP module requires an additional
974 attribute, but the other attributes are optional and only
975 restrict the key space.
976 Before responding to the
978 transaction, the client
981 use for the rest of the conversation.
982 Because of the arguments in the
984 request, the key must have public attributes
988 as mentioned earlier,
989 the APOP module additionally requires that the key have
994 Now that the client has obtained a response
997 it echoes that response to the server:
999 $P sub C -> P sub S#: APOP gre \f2response\fP
1001 Similarly, the server passes this message to
1004 and obtains another to send back.
1006 $P sub S -> F sub S#: write APOP gre \f2response\fP
1007 $F sub S -> P sub S#: ok
1008 $P sub S -> F sub S#: read
1009 $F sub S -> P sub S#: ok +OK welcome
1011 $P sub S -> P sub C#: +OK welcome
1013 Now the authentication protocol is done, and
1014 the server can retrieve information
1015 about what the protocol established.
1017 $P sub S -> F sub S#: authinfo
1018 $F sub S -> P sub S#: ok client=gre
1019 capability=\f2capability\fP
1024 .I attr\f(CW=\fPvalue
1025 pairs, here a client user name and a capability.
1026 (Protocols that establish shared secrets or provide
1027 mutual authentication indicate this by adding
1029 .I attr\f(CW=\fPvalue
1031 The capability can be used by the server to change its
1032 identity to that of the client, as described earlier.
1033 Once it has changed its identity, the server can access and serve
1034 the client's mailbox.
1036 Two more files provide hooks for a graphical
1041 allows the user detailed control over the use of certain keys.
1044 attribute, then the user must approve each use of the key.
1045 A separate program with a graphical interface reads from the
1047 file to see when a confirmation is necessary.
1048 The read blocks until a key usage needs to be approved, whereupon
1049 it will return a line of the form
1051 confirm tag=1 \f2attributes\fP
1053 requesting permission to use the key with those public attributes.
1054 The graphical interface then prompts the user for approval
1064 diverts key requests.
1065 In the APOP example, if a suitable key had not been found
1070 would have indicated failure by
1071 returning a response indicating
1072 what key was needed:
1074 $F sub C -> P sub C#: needkey proto=apop
1075 server=x.y.com user? !password?
1077 A typical client would then prompt the user for the desired
1078 key information, create a new key via the
1080 file, and then reissue the
1086 then instead of failing, the transaction
1087 will block, and the next read from the
1088 .CW /mnt/factotum/needkey
1089 file will return a line of the form
1091 needkey tag=1 \f2attributes\f2
1093 The graphical interface then prompts the user for the needed
1094 key information, creates the key via the
1096 file, and writes back
1098 to resume the transaction.
1100 The remaining files are informational and used for debugging.
1103 file contains a list of supported protocols (to see what protocols the
1106 .CW /mnt/factotum/proto ),
1109 file contains a log of operations and debugging output
1114 The next few sections explain how
1116 is used by system services.
1118 Authentication in 9P
1120 Plan 9 uses a remote file access protocol, 9P
1122 to connect to resources such as the
1123 file server and remote processes.
1124 The original design for 9P included special messages at the start of a conversation
1125 to authenticate the user.
1126 Multiple users can share a single connection, such as when a CPU server
1127 runs processes for many users connected to a single file server,
1128 but each must authenticate separately.
1129 The authentication protocol, similar to that of Kerberos
1131 used a sequence of messages passed between client, file server, and authentication
1132 server to verify the identities of the user, calling machine, and serving machine.
1133 One major drawback to the design was that the authentication method was defined by 9P
1134 itself and could not be changed.
1135 Moreover, there was no mechanism to relegate
1136 authentication to an external (trusted) agent,
1137 so a process implementing 9P needed, besides support for file service,
1138 a substantial body of cryptographic code to implement a handful of startup messages
1141 A recent redesign of 9P
1142 addressed a number of file service issues outside the scope of this paper.
1143 On issues of authentication, there were two goals:
1144 first, to remove details about authentication from the
1145 protocol itself; second, to allow an external program to execute the authentication
1146 part of the protocol.
1147 In particular, we wanted a way to quickly incorporate
1148 ideas found in other systems such as SFS
1151 Since 9P is a file service protocol, the solution involved creating a new type of file
1155 Connections to a 9P service begin in a state that
1156 allows no general file access but permits the client
1157 to open an authentication file
1158 by sending a special message, generated by the new
1162 afd = fauth(int fd, char *servicename);
1166 is the user's file descriptor for the established network connection to the 9P server
1169 is the name of the desired service offered on that server, typically the file subsystem
1171 The returned file descriptor,
1173 is a unique handle representing the authentication file
1174 created for this connection to authenticate to
1175 this service; it is analogous to a capability.
1176 The authentication file represented by
1178 is not otherwise addressable on the server, such as through
1179 the file name hierarchy.
1180 In all other respects, it behaves like a regular file;
1181 most important, it accepts standard read and write operations.
1183 To prove its identity, the user process (via
1185 executes the authentication protocol,
1186 described in the next section of this paper,
1189 file descriptor with ordinary reads and writes.
1190 When client and server have successfully negotiated, the authentication file
1191 changes state so it can be used as evidence of authority in
1194 Once identity is established, the process presents the (now verified)
1196 as proof of identity to the
1200 mount(int fd, int afd, char *mountpoint,
1201 int flag, char *servicename)
1205 succeeds, the user now
1206 has appropriate permissions for the file hierarchy made
1207 visible at the mount point.
1209 This sequence of events has several advantages.
1210 First, the actual authentication protocol is implemented using regular reads and writes,
1211 not special 9P messages, so
1212 they can be processed, forwarded, proxied, and so on by
1213 any 9P agent without special arrangement.
1214 Second, the business of negotiating the authentication by reading and writing the
1215 authentication file can be delegated to an outside agent, in particular
1217 the programs that implement the client and server ends of a 9P conversation need
1218 no authentication or cryptographic code.
1220 since the authentication protocol is not defined by 9P itself, it is easy to change and
1221 can even be negotiated dynamically.
1224 acts like a capability, it can be treated like one:
1225 handed to another process to give it special permissions;
1226 kept around for later use when authentication is again required;
1227 or closed to make sure no other process can use it.
1229 All these advantages stem from moving the authentication negotiation into
1230 reads and writes on a separate file.
1231 As is often the case in Plan 9,
1232 making a resource (here authentication) accessible with a file-like interface
1236 the need for special interfaces.
1239 Plan 9 shared key protocol
1241 In addition to the various standard protocols supported by
1243 we use a shared key protocol for native
1244 Plan 9 authentication.
1245 This protocol provides backward compatibility with
1246 older versions of the system. One reason for the new
1247 architecture is to let us replace such protocols
1248 in the near future with more cryptographically secure ones.
1251 is a shared key protocol that uses tickets much like those
1252 in the original Kerberos.
1253 The difference is that we've
1254 replaced the expiration time in Kerberos tickets with
1255 a random nonce parameter and a counter.
1256 We summarize it here:
1258 $C -> S: ~~ "nonce" sub C#
1259 $S -> C: ~~ "nonce" sub S , "uid" sub S , "domain" sub S#
1261 $C -> A: ~~ "nonce" sub S , "uid" sub S , "domain" sub S , "uid" sub C ,#
1263 $A -> C: ~~ K sub C roman "{" "nonce" sub S , "uid" sub C , "uid" sub S, K sub n roman "}",#
1264 $K sub S roman "{" "nonce" sub S , "uid" sub C , "uid" sub S, K sub n roman "}"#
1266 $C -> S: ~~ K sub S roman "{" "nonce" sub S , "uid" sub C , "uid" sub S , K sub n roman "}",#
1267 $K sub n roman "{" "nonce" sub S , "counter" roman "}"#
1268 $S -> C: ~~ K sub n roman "{" "nonce" sub C , "counter" roman "}"#
1270 (Here $K roman "{" x roman "}"# indicates $x# encrypted with
1272 The first two messages exchange nonces and server identification.
1273 After this initial exchange, the client contacts the authentication
1274 server to obtain a pair of encrypted tickets, one encrypted with
1275 the client key and one with the server key.
1276 The client relays the server ticket to the server.
1277 The server believes that the ticket is new
1280 and that the ticket is from the authentication
1281 server because it is encrypted in the server key $K sub S#.
1282 The ticket is basically a statement from the authentication
1283 server that now $"uid" sub C# and $"uid" sub S# share a
1285 The authenticator $K sub n roman "{" "nonce" sub S , "counter" roman "}"#
1286 convinces the server that the client knows $K sub n# and thus
1287 must be $"uid" sub C#.
1288 Similarly, authenticator $K sub n roman "{" "nonce" sub C , "counter" roman "}"#
1289 convinces the client that the server knows $K sub n# and thus
1290 must be $"uid" sub S#.
1291 Tickets can be reused, without contacting the authentication
1292 server again, by incrementing the counter before each
1293 authenticator is generated.
1295 In the future we hope to introduce a public key version of
1297 which would allow authentication even
1298 when the authentication server is not available.
1300 The authentication server
1302 Each Plan 9 security domain has an authentication server (AS)
1303 that all users trust to keep the complete set of shared keys.
1304 It also offers services for users and administrators to manage the
1305 keys, create and disable accounts, and so on.
1306 It typically runs on
1307 a standalone machine with few other services.
1308 The AS comprises two services,
1314 is a user-level file system that manages an
1315 encrypted database of user accounts.
1316 Each account is represented by a directory containing the
1319 containing the Plan 9 key for p9sk1;
1321 for the challenge/response protocols (APOP, VNC, CHAP, MSCHAP,
1324 for authentication outcomes;
1326 for an expiration time; and
1328 If the expiration time passes,
1329 if the number of successive failed authentications
1332 is written to the status file,
1333 any attempt to access the
1340 is a network service that brokers shared key authentications
1341 for the protocols p9sk1, APOP, VNC, CHAP, MSCHAP,
1342 and CRAM. Remote users can also call
1344 to change their passwords.
1348 protocol was described in the previous
1350 The challenge/response protocols differ
1351 in detail but all follow the general structure:
1353 $C -> S: ~~ "nonce" sub C#
1354 $S -> C: ~~ "nonce" sub S , "uid" sub S ,"domain" sub S#
1355 $C -> A: ~~ "nonce" sub S , "uid" sub S , "domain" sub S ,#
1356 $"hostid" sub C , "uid" sub C#
1357 $A -> C: ~~ K sub C roman "{" "nonce" sub S , "uid" sub C , "uid" sub S, K sub n roman "}",#
1358 $K sub S roman "{" "nonce" sub S , "uid" sub C , "uid" sub S, K sub n roman "}"#
1359 $C -> S: ~~ K sub S roman "{" "nonce" sub S , "uid" sub C , "uid" sub S, K sub n roman "}",#
1360 $K sub n roman "{" "nonce" sub S roman "}"#
1361 $S -> C: ~~ K sub n roman "{" "nonce" sub C roman "}"#
1363 The password protocol is:
1365 $C -> A: ~~ "uid" sub C#
1366 $A -> C: ~~ K sub c roman "{" K sub n roman "}"#
1367 $C -> A: ~~ K sub n roman "{" "password" sub "old" , "password" sub "new" roman "}"#
1370 To avoid replay attacks, the pre-encryption
1371 clear text for each of the protocols (as well as for p9sk1) includes
1372 a tag indicating the encryption's role in the
1373 protocol. We elided them in these outlines.
1375 Protocol negotiation
1377 Rather than require particular protocols for particular services,
1378 we implemented a negotiation metaprotocol,
1380 which chooses the actual authentication protocol to use.
1382 is used now by all native services on Plan 9.
1384 The metaprotocol is simple. The callee sends a
1385 null-terminated string of the form:
1387 v.$n# $proto sub 1#@$domain sub 1# $proto sub 2#@$domain sub 2# ...
1391 is a decimal version number, $proto sub k#
1392 is the name of a protocol for which the
1394 has a key, and $domain sub k#
1395 is the name of the domain in which the key is
1397 The caller then responds
1399 \f2proto\fP@\f2domain\fP
1401 indicating its choice.
1402 Finally the callee responds
1406 Any other string indicates failure.
1407 At this point the chosen protocol commences.
1408 The final fixed-length reply is used to make it easy to
1409 delimit the I/O stream should the chosen protocol
1410 require the caller rather than the callee to send the first message.
1412 With this negotiation metaprotocol, the underlying
1413 authentication protocols used for Plan 9 services
1414 can be changed under any application just
1415 by changing the keys known by the
1419 P9any is vulnerable to man in the middle attacks
1420 to the extent that the attacker may constrain the
1421 possible choices by changing the stream. However,
1422 we believe this is acceptable since the attacker
1423 cannot force either side to choose algorithms
1424 that it is unwilling to use.
1426 Library Interface to Factotum
1428 Although programs can access
1430 services through its file system interface,
1431 it is more common to use a C library that
1432 packages the interaction.
1433 There are a number of routines in the library,
1434 not all of which are relevant here, but a few
1435 examples should give their flavor.
1437 First, consider the problem of mounting a remote file server using 9P.
1438 An earlier discussion showed how the
1442 system calls use an authentication file,
1449 The library contains a routine,
1451 (authenticated mount), that is used by most programs in preference to
1462 here is the complete code:
1466 amount(int fd, char *mntpt,
1467 int flags, char *aname)
1472 afd = fauth(fd, aname);
1474 ai = auth_proxy(afd, amount_getkey,
1475 "proto=p9any role=client");
1479 ret = mount(fd, afd, mntpt,
1488 is a file descriptor returned by
1492 for a new connection to a file server.
1493 The conversation with
1495 occurs in the call to
1497 which specifies, as a key query,
1498 which authentication protocol to use
1499 (here the metaprotocol
1501 and the role being played
1504 will read and write the
1506 files, and the authentication file descriptor
1508 to validate the user's right to access the service.
1509 If the call is successful, any auxiliary data, held in an
1511 structure, is freed.
1514 is then called with the (perhaps validated)
1516 A 9P server can cause the
1518 system call to fail, as an indication that authentication is
1519 not required to access the service.
1521 The second argument to
1525 to be called if secret information such as a password or
1526 response to a challenge is required as part of the authentication.
1527 This function, of course, will provide this data to
1532 .CW /mnt/factotum/ctl
1535 Although the final argument to
1537 in this example is a simple string, in general
1538 it can be a formatted-print specifier in the manner of
1540 to enable the construction of more elaborate key queries.
1542 As another example, consider the Plan 9
1544 service, which exports local devices to a shell process on
1545 a remote machine, typically
1546 to connect the local screen and keyboard to a more powerful computer.
1549 is a superset of a service called
1552 which allows one machine to see an arbitrary portion of the file name space
1553 of another machine, such as to
1554 export the network device to another machine
1560 because it also delivers signals such as interrupt
1561 and negotiates the initial environment
1562 for the remote shell.
1564 To authenticate an instance of
1568 processes on both ends: the local, client
1569 end running as the user on a terminal
1570 and the remote, server
1571 end running as the host owner of the server machine.
1572 Here is schematic code for the two ends:
1581 ai = auth_proxy(fd, auth_getkey,
1582 "proto=p9any role=client");
1586 /* start cpu protocol here */
1591 srvp9auth(int fd, char *user)
1595 ai = auth_proxy(fd, NULL,
1596 "proto=p9any role=server");
1599 /* set user id for server process */
1600 if(auth_chuid(ai, NULL) < 0)
1603 /* start cpu protocol here */
1607 encapsulates the negotiation to change a user id using the
1611 files of the (server) kernel.
1612 Note that although the client process may ask the user for new keys, using
1614 the server machine, presumably a shared machine with a pseudo-user for
1615 the host owner, sets the key-getting function to
1621 keeps its keys in volatile memory, which must somehow be
1622 initialized at boot time.
1626 supplemented by a persistent store, perhaps
1627 a floppy disk containing a key file of commands to be copied into
1628 .CW /mnt/factotum/ctl
1630 But removable media are a nuisance to carry and
1631 are vulnerable to theft.
1632 Keys could be stored encrypted on a shared file system, but
1633 only if those keys are not necessary for authenticating to
1634 the file system in the first place.
1635 Even if the keys are encrypted under a user
1636 password, a thief might well succeed with a dictionary attack.
1637 Other risks of local storage are loss of the contents
1638 through mechanical mishap or dead batteries.
1639 Thus for convenience and
1642 (secure store) server in the network to hold each user's permanent list of keys, a
1647 is a file server for encrypted data,
1648 used only during bootstrapping.
1649 It must provide strong
1650 authentication and resistance to passive and active protocol attacks
1651 while assuming nothing more from the client than a password.
1654 has loaded the key file, further encrypted or authenticated
1655 file storage can be accomplished by standard mechanisms.
1657 define mod % ~ roman "mod" ~ %
1658 define sha1 % "sha1" %
1661 The cryptographic technology that enables
1663 is a form of encrypted
1676 because it comes with a proof of equivalence in strength to
1677 Diffie-Hellman; subtle flaws in some earlier encrypted key exchange
1678 protocols and implementations have encouraged us to take special care.
1679 In outline, the PAK protocol is:
1681 $C -> S:~ C, g sup x H#
1682 $S -> C:~ S, g sup y , hash(g sup xy , C, S)#
1683 $C -> S:~ hash(g sup xy , S, C)#
1685 where $H# is a preshared secret between client $C# and server $S#.
1686 There are several variants of PAK, all presented in papers
1687 mainly concerned with proofs of cryptographic properties.
1688 To aid implementers, we have distilled a description of the specific
1689 version we use into an Appendix to this paper.
1690 The Plan 9 open source license provides for use of Lucent's
1691 encrypted key exchange patents in this context.
1693 As a further layer of defense against password theft,
1694 we provide (within the encrypted channel $C -> S#)
1695 information that is validated at a RADIUS server,
1696 such as the digits from a hardware token
1698 This provides two-factor authentication, which potentially
1699 requires tricking two independent administrators in any attack by
1702 The key file stored on the server is encrypted with AES (Rijndael) using CBC
1703 with a 10-byte initialization vector and trailing authentication padding.
1704 All this is invisible to the user of
1706 For that matter, it is invisible to the
1709 if the AES Modes of Operation are standardized and a new encryption format
1710 designed, it can be implemented by a client without change to the server.
1713 is deliberately not backed up; the user is expected to
1716 or save the key file on removable media
1718 The user's password is hashed to create the $H# used
1719 in the PAK protocol; a different hash of the password is used as
1720 the file encryption key.
1721 Finally, there is a command (inside the authenticated,
1722 encrypted channel between client and
1724 to change passwords by sending
1726 for consistency, the client process must at the same time fetch and re-encrypt all files.
1730 starts, it dials the local
1732 and checks whether the user has an account.
1734 it prompts for the user's
1736 password and fetches the key file.
1738 ensures mutual authentication and prevents dictionary attacks on the password
1739 by passive wiretappers or active intermediaries.
1741 the key file can be long random strings suitable for
1742 simpler challenge/response authentication protocols.
1743 Thus the user need only remember
1744 a single, weaker password to enable strong, ``single sign on'' authentication to
1745 unchanged legacy applications scattered across multiple authentication domains.
1747 Transport Layer Security
1749 Since the Plan 9 operating system is designed for use in network elements
1750 that must withstand direct attack, unguarded by firewall or VPN, we seek
1751 to ensure that all applications use channels with appropriate mutual
1752 authentication and encryption.
1753 A principal tool for this is TLS 1.0
1755 (TLS 1.0 is nearly the same as SSL 3.0,
1756 and our software is designed to interoperate
1757 with implementations of either standard.)
1759 TLS defines a record layer protocol for message integrity and privacy
1760 through the use of message digesting and encryption with shared secrets.
1761 We implement this service as a kernel device, though it could
1762 be performed at slightly higher cost by invoking a separate program.
1763 The library interface to the TLS kernel device is:
1765 int pushtls(int fd, char *hashalg,
1766 char *cryptalg, int isclient,
1767 char *secret, char *dir);
1769 Given a file descriptor, the names of message digest and
1770 encryption algorithms, and the shared secret,
1772 returns a new file descriptor for the encrypted connection.
1775 receives the name of the directory in the TLS device that
1776 is associated with the new connection.)
1777 The function is named by analogy with the ``push'' operation
1778 supported by the stream I/O system of Research Unix and the
1779 first two editions of Plan 9.
1780 Because adding encryption is as simple as replacing one
1781 file descriptor with another, adding encryption to a particular
1782 network service is usually trivial.
1784 The Plan 9 shared key authentication protocols establish a shared 56-bit secret
1786 Native Plan 9 network services such as
1790 use these protocols for authentication and then invoke
1792 with the shared secret.
1794 Above the record layer, TLS specifies a handshake protocol using public keys
1795 to establish the session secret.
1796 This protocol is widely used with HTTP and IMAP4
1797 to provide server authentication, though with client certificates it could provide
1798 mutual authentication. The library function
1800 int tlsClient(int fd, TLSconn *conn)
1802 handles the initial handshake and returns the result of
1804 On return, it fills the
1806 structure with the session ID used
1807 and the X.509 certificate presented by the
1808 server, but makes no effort to verify the certificate.
1809 Although the original design intent of X.509 certificates expected
1810 that they would be used with a Public Key Infrastructure,
1811 reliable deployment has been so long delayed and problematic
1812 that we have adopted the simpler policy of just using the
1813 X.509 certificate as a representation of the public key,
1814 depending on a locally-administered directory of SHA1 thumbprints
1815 to allow applications to decide which public keys to trust
1818 Related Work and Discussion
1820 Kerberos, one of the earliest distributed authentication
1821 systems, keeps a set of authentication tickets in a temporary file called
1822 a ticket cache. The ticket cache is protected by Unix file permissions.
1823 An environment variable containing the file name of the ticket cache
1824 allows for different ticket caches in different simultaneous login sessions.
1825 A user logs in by typing his or her Kerberos password.
1826 The login program uses the Kerberos password to obtain a temporary
1827 ticket-granting ticket from the authentication server, initializes the
1828 ticket cache with the ticket-granting ticket, and then forgets the password.
1829 Other applications can use the ticket-granting ticket to sign tickets
1830 for themselves on behalf of the user during the login session.
1831 The ticket cache is removed when the user logs out
1833 The ticket cache relieves the user from typing a password
1834 every time authentication is needed.
1836 The secure shell SSH develops this idea further, replacing the
1837 temporary file with a named Unix domain socket connected to
1838 a user-level program, called an agent.
1839 Once the SSH agent is started and initialized with one or
1840 more RSA private keys, SSH clients can employ it
1841 to perform RSA authentications on their behalf.
1842 In the absence of an agent, SSH typically uses RSA keys
1843 read from encrypted disk files or uses passphrase-based
1844 authentication, both of which would require prompting the user
1845 for a passphrase whenever authentication is needed
1847 The self-certifying file system SFS uses a similar agent
1849 not only for moderating the use of client authentication keys
1850 but also for verifying server public keys
1854 is a logical continuation of this evolution,
1855 replacing the program-specific SSH or SFS agents with
1856 a general agent capable of serving a wide variety of programs.
1857 Having one agent for all programs removes the need
1858 to have one agent for each program.
1859 It also allows the programs themselves to be protocol-agnostic,
1860 so that, for example, one could build an SSH workalike
1861 capable of using any protocol supported by
1863 without that program knowing anything about the protocols.
1864 Traditionally each program needs to implement each
1865 authentication protocol for itself, an $O(n sup 2 )# coding
1870 Previous work on agents has concentrated on their use by clients
1871 authenticating to servers.
1872 Looking in the other direction, Sun Microsystem's
1873 pluggable authentication module (PAM) is one
1874 of the earliest attempts to
1875 provide a general authentication mechanism for Unix-like
1878 Without a central authority like PAM, system policy is tied
1879 up in the various implementations of network services.
1880 For example, on a typical Unix, if a system administrator
1881 decides not to allow plaintext passwords for authentication,
1882 the configuration files for a half dozen different servers \(em
1889 PAM solves this problem by hiding the details of a given
1890 authentication mechanism behind a common library interface.
1891 Directed by a system-wide configuration file,
1892 an application selects a particular authentication mechanism
1893 by dynamically loading the appropriate shared library.
1894 PAM is widely used on Sun's Solaris and some Linux distributions.
1897 achieves the same goals
1898 using the agent approach.
1900 is the only process that needs to create
1901 capabilities, so all the network servers can run as
1902 untrusted users (e.g.,
1907 which greatly reduces the harm done if a server is buggy
1911 were implemented on Unix along with
1912 an analogue to the Plan 9 capability device, venerable
1917 would no longer need to be installed ``setuid root.''
1919 Several other systems, such as Password Safe [Schn],
1920 store multiple passwords in an encrypted file,
1921 so that the user only needs to remember one password.
1924 solution differs from these by placing the storage in
1925 a hardened location in the network, so that the encrypted file is
1926 less liable to be stolen for offline dictionary attack and so that
1927 it is available even when a user has several computers.
1928 In contrast, Microsoft's Passport system
1930 keeps credentials in
1931 the network, but centralized at one extremely-high-value target.
1932 The important feature of Passport, setting up trust relationships
1933 with e-merchants, is outside our scope.
1936 architecture is almost identical to
1937 Perlman and Kaufman's
1939 but with newer EKE technology.
1940 Like them, we chose to defend mainly against outside attacks
1943 if additional defense of the files on the server
1944 itself is desired, one can use distributed techniques
1947 We made a conscious choice of placing encryption, message integrity,
1948 and key management at the application layer
1949 (TLS, just above layer 4) rather than at layer 3, as in IPsec.
1950 This leads to a simpler structure for the network stack, easier
1951 integration with applications and, most important, easier network
1952 administration since we can recognize which applications are misbehaving
1953 based on TCP port numbers. TLS does suffer (relative to IPsec) from
1954 the possibility of forged TCP Reset, but we feel that this is adequately
1955 dealt with by randomized TCP sequence numbers.
1956 In contrast with other TLS libraries, Plan 9 does not
1957 require the application to change
1961 but simply to add a few lines of code at startup
1966 Writing safe code is difficult.
1968 mistakes in logic, and bugs in compilers and operating systems
1969 can each make it possible for an attacker
1970 to subvert the intended execution sequence of a
1972 If the server process has the privileges
1973 of a powerful user, such as
1975 on Unix, then so does the attacker.
1978 to constrain the privileged execution to a single
1979 process whose core is a few thousand lines of code.
1980 Verifying such a process, both through manual and automatic means,
1981 is much easier and less error prone
1982 than requiring it of all servers.
1984 An implementation of these ideas is in Plan 9 from Bell Labs, Fourth Edition,
1985 freely available from \f(CWhttp://\%plan9.bell-labs.com/\%plan9\fP.
1989 William Josephson contributed to the implementation of password changing in
1991 We thank Phil MacKenzie and Martín Abadi for helpful comments on early parts
1999 predominantly Dutchmen, gave helpful comments on the paper.
2000 Russ Cox is supported by a fellowship from the Fannie and John Hertz Foundation.
2005 S.M. Bellovin and M. Merritt,
2006 ``Augmented Encrypted Key Exchange,''
2007 Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 244 - 250.
2010 Victor Boyko, Philip MacKenzie, and Sarvar Patel,
2011 ``Provably Secure Password-Authenticated Key Exchange using Diffie-Hellman,''
2012 Eurocrypt 2000, 156\-171.
2013 ... http://www.bell-labs.com/who/philmac/research/pak-final.ps.gz
2016 T . Dierks and C. Allen,
2017 ``The TLS Protocol, Version 1.0,''
2021 Warwick Ford and Burton S. Kaliski, Jr.,
2022 ``Server-Assisted Generation of a Strong Secret from a Password,''
2023 IEEE Fifth International Workshop on Enterprise Security,
2024 National Institute of Standards and Technology (NIST),
2025 Gaithersburg MD, June 14 - 16, 2000.
2029 ``Strong Password-Only Authenticated Key Exchange,''
2030 \f(CWhttp://\%integritysciences.com/\%speke97.html\fP.
2034 ``Flexible Key Management with SFS Agents,''
2035 Master's Thesis, MIT, May 2000.
2039 private communication.
2042 David Mazières, Michael Kaminsky, M. Frans Kaashoek and Emmett Witchel,
2043 ``Separating key management from file system security,''
2044 Symposium on Operating Systems Principles, 1999, pp. 124-139.
2048 \f(CWhttp://\%www.passport.com/\fP.
2051 Radia Perlman and Charlie Kaufman,
2052 ``Secure Password-Based Protocol for Downloading a Private Key,''
2053 Proc. 1999 Network and Distributed System Security Symposium,
2054 Internet Society, January 1999.
2057 Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, and Phil Winterbottom,
2058 ``Plan 9 from Bell Labs,''
2059 Computing Systems, \f3\&8\fP, 3, Summer 1995, pp. 221-254.
2062 Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom,
2063 ``The Use of Name Spaces in Plan 9,''
2064 Operating Systems Review, \f3\&27\fP, 2, April 1993, pp. 72-76
2065 (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop,
2066 Mont Saint-Michel, 1992, Paper nº 34).
2070 ``SSL and TLS: Designing and Building Secure Systems,''
2071 Addison-Wesley, 2001. ISBN 0-201-61598-3, p. 387.
2074 C. Rigney, A. Rubens, W. Simpson, S. Willens,
2075 ``Remote Authentication Dial In User Service (RADIUS),''
2076 RFC2138, April 1997.
2079 Ronald L. Rivest and Butler Lampson,
2080 ``SDSI\(emA Simple Distributed Security Infrastructure,''
2081 \f(CWhttp://\%theory.lcs.mit.edu/\%~rivest/\%sdsi10.ps\fP.
2084 Bruce Schneier, Password Safe,
2085 \f(CWhttp://\%www.counterpane.com/\%passsafe.html\fP.
2089 ``Unified Login with Pluggable Authentication Modules (PAM),''
2090 Proceedings of the Third ACM Conference on Computer Communications and Security,
2091 March 1996, New Delhi, India.
2092 ... http://www1.acm.org/pubs/articles/proceedings/commsec/238168/p1-samar/p1-samar.pdf
2095 Jennifer G. Steiner, Clifford Neumann, and Jeffrey I. Schiller,
2096 ``\fIKerberos\fR: An Authentication Service for Open Network Systems,''
2097 Proceedings of USENIX Winter Conference, Dallas, Texas, February 1988, pp. 191\-202.
2098 ... ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS
2102 ``The Secure Remote Password Protocol,''
2104 the 1998 Internet Society Network and Distributed System Security
2105 Symposium, San Diego, CA, March 1998, pp. 97-111.
2109 ``SSH\(emSecure Login Connections Over the Internet,''
2110 6th USENIX Security Symposium, pp. 37-42. San Jose, CA, July 1996.
2112 Appendix: Summary of the PAK protocol
2114 Let $q>2 sup 160# and $p>2 sup 1024# be primes
2115 such that $p=rq+1# with $r# not a multiple of $q#.
2116 Take $h ∈ Z sub p sup *# such that $g == h sup r# is not 1.
2117 These parameters may be chosen by the NIST algorithm for DSA,
2118 and are public, fixed values.
2119 The client $C# knows a secret $pi#
2120 and computes $H == (H sub 1 (C, ~ pi )) sup r# and $H sup -1#,
2121 where $H sub 1# is a hash function yielding a random element of $Z sub p sup *#,
2122 and $H sup -1# may be computed by gcd.
2123 (All arithmetic is modulo $p#.)
2124 The client gives $H sup -1# to the server $S# ahead of time by a private channel.
2125 To start a new connection, the client generates a random value $x#,
2126 computes $m == g sup x H#,
2127 then calls the server and sends $C# and $m#.
2128 The server checks $m != 0 mod p#,
2129 generates random $y#,
2130 computes $ mu == g sup y#,
2131 $ sigma == (m H sup -1 ) sup y#,
2132 and sends $S#, $mu#, $k == sha1 ( roman "\"server\"", C, S, m, mu , sigma , H sup -1 )#.
2133 Next the client computes $sigma = mu sup x#,
2135 and sends $k' == sha1 ( roman "\"client\"", C, S, m, mu , sigma , H sup -1 )#.
2136 The server then verifies $k'# and both sides begin
2137 using session key $K == sha1 ( roman "\"session\"", C, S, m, mu , sigma , H sup -1 )#.
2138 In the published version of PAK, the server name $S#
2139 is included in the initial
2140 hash $H#, but doing so is inconvenient in our application,
2141 as the server may be known by various equivalent names.
2146 equivalence proof [Boyk00]
2147 can be adapted to cover our version.