auth.html 76 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646164716481649165016511652165316541655165616571658165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730173117321733173417351736173717381739174017411742174317441745174617471748174917501751175217531754175517561757175817591760176117621763176417651766176717681769177017711772177317741775177617771778177917801781178217831784178517861787178817891790179117921793179417951796179717981799180018011802180318041805180618071808180918101811181218131814181518161817181818191820182118221823182418251826182718281829183018311832183318341835183618371838183918401841184218431844184518461847184818491850185118521853185418551856185718581859186018611862186318641865186618671868186918701871187218731874187518761877187818791880188118821883188418851886188718881889189018911892189318941895189618971898189919001901190219031904190519061907190819091910191119121913191419151916191719181919192019211922192319241925192619271928192919301931193219331934193519361937193819391940194119421943194419451946194719481949195019511952195319541955195619571958195919601961196219631964196519661967196819691970197119721973197419751976197719781979198019811982198319841985198619871988198919901991199219931994199519961997199819992000200120022003200420052006200720082009201020112012201320142015201620172018201920202021202220232024202520262027202820292030203120322033203420352036203720382039204020412042204320442045204620472048204920502051205220532054205520562057205820592060206120622063206420652066206720682069207020712072207320742075207620772078207920802081208220832084208520862087208820892090209120922093209420952096
  1. <html>
  2. <br><img src="-.19111510.gif"><br>
  3. <title>
  4. -
  5. </title>
  6. <body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
  7. <H1>Security in Plan 9
  8. </H1>
  9. <DL><DD><I>Russ Cox, MIT LCS<br>
  10. <br>
  11. Eric Grosse, Bell Labs<br>
  12. <br>
  13. Rob Pike, Bell Labs<br>
  14. <br>
  15. Dave Presotto, Avaya Labs and Bell Labs<br>
  16. <br>
  17. Sean Quinlan, Bell Labs<br>
  18. <br>
  19. <TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com</TT>
  20. </I></DL>
  21. <DL><DD><H4>ABSTRACT</H4>
  22. The security architecture of the Plan 9(tm)
  23. operating system has recently been redesigned
  24. to address some technical shortcomings.
  25. This redesign provided an opportunity also to make the system more
  26. convenient to use securely.
  27. Plan 9 has thus improved in two ways not usually seen together:
  28. it has become more secure
  29. <I>and</I>
  30. easier to use.
  31. <br>&#32;<br>
  32. The central component of the new architecture is a per-user
  33. self-contained agent called
  34. <TT>factotum</TT>.
  35. <TT>Factotum</TT>
  36. securely holds a
  37. copy of the user's keys and negotiates authentication protocols, on
  38. behalf of the user, with secure services around the network.
  39. Concentrating security code in a single program offers several
  40. advantages including: ease of update or repair to broken security
  41. software and protocols; the ability to run secure services at a lower
  42. privilege level; uniform management of keys for all services; and an
  43. opportunity to provide single sign on, even to unchanged legacy
  44. applications.
  45. <TT>Factotum</TT>
  46. has an unusual architecture: it is implemented
  47. as a Plan 9 file server.
  48. <DL>
  49. <DT><DT>&#32;<DD>
  50. NOTE:<I> To appear, in a slightly different form, in
  51. Proc. of the 2002 Usenix Security Symposium,
  52. San Francisco.
  53. </I><DT>&#32;<DD></dl>
  54. <br>
  55. </DL>
  56. <H4>1 Introduction
  57. </H4>
  58. <br>&#32;<br>
  59. Secure computing systems face two challenges:
  60. first, they must employ sophisticated technology that is difficult to design
  61. and prove correct; and second,
  62. they must be easy for regular people to use.
  63. The question of ease of use is sometimes neglected, but it is essential:
  64. weak but easy-to-use security can be more effective than strong but
  65. difficult-to-use security if it is more likely to be used.
  66. People lock their front doors when they leave the house, knowing
  67. full well that a burglar is capable of picking the lock (or avoiding
  68. the door altogether); yet few would accept the cost and
  69. awkwardness of a bank vault door on the
  70. house even though that might reduce the probability of a robbery.
  71. A related point is that users need a clear model of how the security
  72. operates (if not how it actually provides security) in order to use it
  73. well; for example, the clarity of a lock icon on a web browser
  74. is offset by the confusing and typically insecure
  75. steps for installing X.509 certificates.
  76. <br>&#32;<br>
  77. The security architecture of the Plan 9
  78. operating system
  79. [Pike95]
  80. has recently been redesigned to make it both more secure
  81. and easier to use.
  82. By
  83. <I>security</I>
  84. we mean three things:
  85. first, the business of authenticating users and services;
  86. second, the safe handling, deployment, and use of keys
  87. and other secret information; and
  88. third, the use of encryption and integrity checks
  89. to safeguard communications
  90. from prying eyes.
  91. <br>&#32;<br>
  92. The old security architecture of Plan 9
  93. had several engineering problems in common with other operating systems.
  94. First, it had an inadequate notion of security domain.
  95. Once a user provided a password to connect to a local file store,
  96. the system required that the same password be used to access all the other file
  97. stores.
  98. That is, the system treated all network services as
  99. belonging to the same security domain.
  100. <br>&#32;<br>
  101. Second, the algorithms and protocols used in authentication,
  102. by nature tricky and difficult to get right, were compiled into the
  103. various applications, kernel modules, and file servers.
  104. Changes and fixes to a security protocol
  105. required that all components using that protocol needed to be recompiled,
  106. or at least relinked, and restarted.
  107. <br>&#32;<br>
  108. Third, the file transport protocol, 9P
  109. [Pike93],
  110. that forms the core of
  111. the Plan 9 system, had its authentication protocol embedded in its design.
  112. This meant that fixing or changing the authentication used by 9P
  113. required deep changes to the system.
  114. If someone were to find a way to break the protocol, the system would
  115. be wide open and very hard to fix.
  116. <br>&#32;<br>
  117. These and a number of lesser problems, combined with a desire
  118. for more widespread use of encryption in the system, spurred us to
  119. rethink the entire security architecture of Plan 9.
  120. <br>&#32;<br>
  121. The centerpiece of the new architecture is an agent,
  122. called
  123. <TT>factotum</TT>,
  124. that handles the user's keys and negotiates all security
  125. interactions with system services and applications.
  126. Like a trusted assistant with a copy of the owner's keys,
  127. <TT>factotum</TT>
  128. does all the negotiation for security and authentication.
  129. Programs no longer need to be compiled with cryptographic
  130. code; instead they communicate with
  131. <TT>factotum</TT>
  132. agents
  133. that represent distinct entities in the cryptographic exchange,
  134. such as a user and server of a secure service.
  135. If a security protocol needs to be added, deleted, or modified,
  136. only
  137. <TT>factotum</TT>
  138. needs to be updated for all system services
  139. to be kept secure.
  140. <br>&#32;<br>
  141. Building on
  142. <TT>factotum</TT>,
  143. we modified
  144. secure services in the system to move
  145. user authentication code into
  146. <TT>factotum</TT>;
  147. made authentication a separable component of the file server protocol;
  148. deployed new security protocols;
  149. designed a secure file store,
  150. called
  151. <TT>secstore</TT>,
  152. to protect our keys but make them easy to get when they are needed;
  153. designed a new kernel module to support transparent use of
  154. Transport Layer Security (TLS)
  155. [RFC2246];
  156. and began using encryption for all communications within the system.
  157. The overall architecture is illustrated in Figure 1a.
  158. <br><img src="-.19111511.gif"><br>
  159. <DL><DT><DD><TT><PRE>
  160. <br><img src="-.19111512.gif"><br>
  161. </PRE></TT></DL>
  162. <br>&#32;<br>
  163. Figure 1a. Components of the security architecture.
  164. Each box is a (typically) separate machine; each ellipse a process.
  165. n(11The ellipses labeled &lt;I&gt;F&lt;/I&gt;&lt;I&gt;X&lt;/I&gt;n(99
  166. are
  167. <TT>factotum</TT>
  168. processes; those labeled
  169. n(11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;X&lt;/I&gt;n(99
  170. are the pieces and proxies of a distributed program.
  171. The authentication server is one of several repositories for users' security information
  172. that
  173. <TT>factotum</TT>
  174. processes consult as required.
  175. <TT>Secstore</TT>
  176. is a shared resource for storing private information such as keys;
  177. <TT>factotum</TT>
  178. consults it for the user during bootstrap.
  179. <br>&#32;<br>
  180. <br><img src="-.19111513.gif"><br>
  181. <br>&#32;<br>
  182. Secure protocols and algorithms are well understood
  183. and are usually not the weakest link in a system's security.
  184. In practice, most security problems arise from buggy servers,
  185. confusing software, or administrative oversights.
  186. It is these practical problems that we are addressing.
  187. Although this paper describes the algorithms and protocols we are using,
  188. they are included mainly for concreteness.
  189. Our main intent is to present a simple security architecture built
  190. upon a small trusted code base that is easy to verify (whether by manual or
  191. automatic means), easy to understand, and easy to use.
  192. <br>&#32;<br>
  193. Although it is a subjective assessment,
  194. we believe we have achieved our goal of ease of use.
  195. That we have achieved
  196. our goal of improved security is supported by our plan to
  197. move our currently private computing environment onto the Internet
  198. outside the corporate firewall.
  199. The rest of this paper explains the architecture and how it is used,
  200. to explain why a system that is easy to use securely is also safe
  201. enough to run in the open network.
  202. <H4>2 An Agent for Security
  203. </H4>
  204. <br>&#32;<br>
  205. One of the primary reasons for the redesign of the Plan 9
  206. security infrastructure was to remove the authentication
  207. method both from the applications and from the kernel.
  208. Cryptographic code
  209. is large and intricate, so it should
  210. be packaged as a separate component that can be repaired or
  211. modified without altering or even relinking applications
  212. and services that depend on it.
  213. If a security protocol is broken, it should be trivial to repair,
  214. disable, or replace it on the fly.
  215. Similarly, it should be possible for multiple programs to use
  216. a common security protocol without embedding it in each program.
  217. <br>&#32;<br>
  218. Some systems use dynamically linked libraries (DLLs) to address these configuration issues.
  219. The problem with this approach is that it leaves
  220. security code in the same address space as the program using it.
  221. The interactions between the program and the DLL
  222. can therefore accidentally or deliberately violate the interface,
  223. weakening security.
  224. Also, a program using a library to implement secure services
  225. must run at a privilege level necessary to provide the service;
  226. separating the security to a different program makes it possible
  227. to run the services at a weaker privilege level, isolating the
  228. privileged code to a single, more trustworthy component.
  229. <br>&#32;<br>
  230. Following the lead of the SSH agent
  231. [Ylon96],
  232. we give each user
  233. an agent process responsible
  234. for holding and using the user's keys.
  235. The agent program is called
  236. <TT>factotum</TT>
  237. because of its similarity to the proverbial servant with the
  238. power to act on behalf of his master because he holds the
  239. keys to all the master's possessions. It is essential that
  240. <TT>factotum</TT>
  241. keep the keys secret and use them only in the owner's interest.
  242. Later we'll discuss some changes to the kernel to reduce the possibility of
  243. <TT>factotum</TT>
  244. leaking information inadvertently.
  245. <br>&#32;<br>
  246. <TT>Factotum</TT>
  247. is implemented, like most Plan 9 services, as a file server.
  248. It is conventionally mounted upon the directory
  249. <TT>/mnt/factotum</TT>,
  250. and the files it serves there are analogous to virtual devices that provide access to,
  251. and control of, the services of the
  252. <TT>factotum</TT>.
  253. The next few sections describe the design of
  254. <TT>factotum</TT>
  255. and how it operates with the other pieces of Plan 9 to provide
  256. security services.
  257. <H4>2.1 Logging in
  258. </H4>
  259. <br>&#32;<br>
  260. To make the discussions that follow more concrete,
  261. we begin with a couple of examples showing how the
  262. Plan 9 security architecture appears to the user.
  263. These examples both involve a user
  264. <TT>gre</TT>
  265. logging in after booting a local machine.
  266. The user may or may not have a secure store in which
  267. all his keys are kept.
  268. If he does,
  269. <TT>factotum</TT>
  270. will prompt him for the password to the secure store
  271. and obtain keys from it, prompting only when a key
  272. isn't found in the store.
  273. Otherwise,
  274. <TT>factotum</TT>
  275. must prompt for each key.
  276. <br>&#32;<br>
  277. In the typescripts, \n
  278. represents a literal newline
  279. character typed to force a default response.
  280. User input is in italics, and
  281. long lines are folded and indented to fit.
  282. <br>&#32;<br>
  283. This first example shows a user logging in without
  284. help from the secure store.
  285. First,
  286. <TT>factotum</TT>
  287. prompts for a user name that the local kernel
  288. will use:
  289. <DL><DT><DD><TT><PRE>
  290. user[none]: gre
  291. </PRE></TT></DL>
  292. (Default responses appear in square brackets.)
  293. The kernel then starts accessing local resources
  294. and requests, through
  295. <TT>factotum</TT>,
  296. a user/password pair to do so:
  297. <DL><DT><DD><TT><PRE>
  298. !Adding key: dom=cs.bell-labs.com
  299. proto=p9sk1
  300. user[gre]: \n
  301. password: ****
  302. </PRE></TT></DL>
  303. Now the user is logged in to the local system, and
  304. the mail client starts up:
  305. <DL><DT><DD><TT><PRE>
  306. !Adding key: proto=apop
  307. server=plan9.bell-labs.com
  308. user[gre]: \n
  309. password: ****
  310. </PRE></TT></DL>
  311. <TT>Factotum</TT>
  312. is doing all the prompting and the applications
  313. being started are not even touching the keys.
  314. Note that it's always clear which key is being requested.
  315. <br>&#32;<br>
  316. Now consider the same login sequence, but in the case where
  317. <TT>gre</TT>
  318. has a secure store account:
  319. <DL><DT><DD><TT><PRE>
  320. user[none]: gre
  321. secstore password: *********
  322. STA PIN+SecurID: *********
  323. </PRE></TT></DL>
  324. That's the last
  325. <TT>gre</TT>
  326. will hear from
  327. <TT>factotum</TT>
  328. unless an attempt is made to contact
  329. a system for which no key is kept in the secure store.
  330. <H4>2.2 The factotum
  331. </H4>
  332. <br>&#32;<br>
  333. Each computer running Plan 9 has one user id that owns all the
  334. resources on that system &#173; the scheduler, local disks,
  335. network interfaces, etc.
  336. That user, the
  337. <I>host owner</I>,
  338. is the closest analogue in Plan 9 to a Unix
  339. <TT>root</TT>
  340. account (although it is far weaker;
  341. rather than having special powers, as its name implies the host owner
  342. is just a regular user that happens to own the
  343. resources of the local machine).
  344. On a single-user system, which we call a terminal,
  345. the host owner is the id of the terminal's user.
  346. Shared servers such as CPU servers normally have a pseudo-user
  347. that initially owns all resources.
  348. At boot time, the Plan 9 kernel starts a
  349. <TT>factotum</TT>
  350. executing as, and therefore with the privileges of,
  351. the host owner.
  352. <br>&#32;<br>
  353. New processes run as
  354. the same user as the process which created them.
  355. When a process must take on the identity of a new user,
  356. such as to provide a login shell
  357. on a shared CPU server,
  358. it does so by proving to the host owner's
  359. <TT>factotum</TT>
  360. that it is
  361. authorized to do so.
  362. This is done by running an
  363. authentication protocol with
  364. <TT>factotum</TT>
  365. to
  366. prove that the process has access to secret information
  367. which only the new user should possess.
  368. For example, consider the setup in Figure 1a.
  369. If a user on the terminal
  370. wants to log in to the CPU server using the
  371. Plan 9
  372. <TT>cpu</TT>
  373. service
  374. [Pike93],
  375. then
  376. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
  377. might be the
  378. <TT>cpu</TT>
  379. client program and
  380. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  381. the
  382. <TT>cpu</TT>
  383. server.
  384. n(11Neither 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99 nor 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
  385. knows the details of the authentication.
  386. They
  387. do need to be able to shuttle messages back and
  388. forth between the two
  389. <TT>factotums</TT>,
  390. but this is
  391. a generic function easily performed without
  392. knowing, or being able to extract, secrets in
  393. the messages.
  394. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
  395. n(11will make a network connection to 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99.
  396. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
  397. and
  398. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  399. will then relay messages between
  400. the
  401. <TT>factotum</TT>
  402. n(11owned by the user, 11&lt;I&gt;F&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99,
  403. n(11and the one owned by the CPU server, 11&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99,
  404. until mutual authentication has been established.
  405. Later
  406. sections describe the RPC between
  407. <TT>factotum</TT>
  408. and
  409. applications and the library functions to support proxy operations.
  410. <br>&#32;<br>
  411. The kernel always uses a single local instance of
  412. <TT>factotum</TT>,
  413. running as the
  414. host owner, for
  415. its authentication purposes, but
  416. a regular user may start other
  417. <TT>factotum</TT>
  418. agents.
  419. In fact, the
  420. <TT>factotum</TT>
  421. representing the user need not be
  422. running on the same machine as its client.
  423. For instance, it is easy for a user on a CPU server,
  424. through standard Plan 9 operations,
  425. to replace the
  426. <TT>/mnt/factotum</TT>
  427. in the user's private file name space on the server
  428. with a connection to the
  429. <TT>factotum</TT>
  430. running on the terminal.
  431. (The usual file system permissions prevent interlopers
  432. from doing so maliciously.)
  433. This permits secure operations on the CPU server to be
  434. transparently validated by the user's own
  435. <TT>factotum</TT>,
  436. so
  437. secrets need never leave the user's terminal.
  438. The SSH agent
  439. [Ylon96]
  440. does much the
  441. same with special SSH protocol messages, but
  442. an advantage to making our agent a file system
  443. is that we need no new mechanism to access our remote
  444. agent; remote file access is sufficient.
  445. <br>&#32;<br>
  446. Within
  447. <TT>factotum</TT>,
  448. each protocol is implemented as a state
  449. machine with a generic interface, so protocols are in
  450. essence pluggable modules, easy to add, modify, or drop.
  451. Writing a message to and reading a message from
  452. <TT>factotum</TT>
  453. each require a separate RPC and result in
  454. a single state transition.
  455. Therefore
  456. <TT>factotum</TT>
  457. always runs to completion on every RPC and never blocks
  458. waiting for input during any authentication.
  459. Moreover, the number of simultaneous
  460. authentications is limited only by the amount of memory we're
  461. willing to dedicate to representing the state machines.
  462. <br>&#32;<br>
  463. Authentication protocols are implemented only
  464. within
  465. <TT>factotum</TT>,
  466. but adding and removing
  467. protocols does require relinking the binary, so
  468. <TT>factotum</TT>
  469. processes (but no others)
  470. need to be restarted in order to take advantage of
  471. new or repaired protocols.
  472. <br>&#32;<br>
  473. At the time of writing,
  474. <TT>factotum</TT>
  475. contains authentication
  476. modules for the Plan 9 shared key protocol (p9sk1),
  477. SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP,
  478. Microsoft PPP's MSCHAP, and VNC's challenge/response.
  479. <H4>2.3 Local capabilities
  480. </H4>
  481. <br>&#32;<br>
  482. A capability system, managed by the kernel, is used to empower
  483. <TT>factotum</TT>
  484. to grant permission to another process to change its user id.
  485. A
  486. kernel device driver
  487. implements two files,
  488. <TT>/dev/caphash</TT>
  489. and
  490. <TT>/dev/capuse</TT>.
  491. The write-only file
  492. <TT>/dev/caphash</TT>
  493. can be opened only by the host owner, and only once.
  494. <TT>Factotum</TT>
  495. opens this file immediately after booting.
  496. <br>&#32;<br>
  497. To use the files,
  498. <TT>factotum</TT>
  499. creates a string of the form
  500. <I>userid1</I><TT>@</TT><I>userid2</I><TT>@</TT><I>random-string</I><TT>,
  501. uses SHA1 HMAC to hash
  502. </TT><I>userid1</I><TT>@</TT><I>userid2</I><TT>
  503. with key
  504. </TT><I>random-string</I><TT>,
  505. and writes that hash to
  506. </TT><TT>/dev/caphash</TT><TT>.
  507. </TT><TT>Factotum</TT><TT>
  508. then passes the original string to another
  509. process on the same machine, running
  510. as user
  511. </TT><I>userid1</I><TT>,
  512. which
  513. writes the string to
  514. </TT><TT>/dev/capuse</TT><TT>.
  515. The kernel hashes the string and looks for
  516. a matching hash in its list.
  517. If it finds one,
  518. the writing process's user id changes from
  519. </TT><I>userid1</I><TT>
  520. to
  521. </TT><I>userid2</I><TT>.
  522. Once used, or if a timeout expires,
  523. the capability is discarded by the kernel.
  524. </TT><br>&#32;<br>
  525. The capabilities are local to the machine on which they are created.
  526. Hence a
  527. <TT>factotum</TT>
  528. running on one machine cannot pass capabilities
  529. to processes on another and expect them to work.
  530. <H4>2.4 Keys
  531. </H4>
  532. <br>&#32;<br>
  533. We define the word
  534. <I>key</I>
  535. to mean not only a secret, but also a description of the
  536. context in which that secret is to be used: the protocol,
  537. server, user, etc. to which it applies.
  538. That is,
  539. a key is a combination of secret and descriptive information
  540. used to authenticate the identities of parties
  541. transmitting or receiving information.
  542. The set of keys used
  543. in any authentication depends both on the protocol and on
  544. parameters passed by the program requesting the authentication.
  545. <br>&#32;<br>
  546. Taking a tip from SDSI
  547. [RiLa],
  548. which represents security information as textual S-expressions,
  549. keys in Plan 9 are represented as plain UTF-8 text.
  550. Text is easily
  551. understood and manipulated by users.
  552. By contrast,
  553. a binary or other cryptic format
  554. can actually reduce overall security.
  555. Binary formats are difficult for users to examine and can only be
  556. cracked by special tools, themselves poorly understood by most users.
  557. For example, very few people know or understand what's inside
  558. their X.509 certificates.
  559. Most don't even know where in the system to
  560. find them.
  561. Therefore, they have no idea what they are trusting, and why, and
  562. are powerless to change their trust relationships.
  563. Textual, centrally stored and managed keys are easier to use and safer.
  564. <br>&#32;<br>
  565. Plan 9 has historically represented databases as attribute/value pairs,
  566. since they are a good foundation for selection and projection operations.
  567. <TT>Factotum</TT>
  568. therefore represents
  569. the keys in the format
  570. <I>attribute</I><TT>=</TT><I>value</I><TT>,
  571. where
  572. </TT><I>attribute</I><TT>
  573. is an identifier, possibly with a single-character prefix, and
  574. </TT><I>value</I><TT>
  575. is an arbitrary quoted string.
  576. The pairs themselves are separated by white space.
  577. For example, a Plan 9 key and an APOP key
  578. might be represented like this:
  579. <DL><DT><DD><TT><PRE>
  580. dom=bell-labs.com proto=p9sk1 user=gre
  581. !password='don''t tell'
  582. proto=apop server=x.y.com user=gre
  583. !password='open sesame'
  584. </PRE></TT></DL>
  585. If a value is empty or contains white space or single quotes, it must be quoted;
  586. quotes are represented by doubled single quotes.
  587. Attributes that begin with an exclamation mark
  588. (</TT><TT>!</TT><TT>)
  589. are considered
  590. </TT><I>secret</I><TT>.
  591. </TT><TT>Factotum</TT><TT>
  592. will never let a secret value escape its address space
  593. and will suppress keyboard echo when asking the user to type one.
  594. </TT><br>&#32;<br>
  595. A program requesting authentication selects a key
  596. by providing a
  597. <I>query</I>,
  598. a list of elements to be matched by the key.
  599. Each element in the list is either an
  600. <I>attribute</I><TT>=</TT><I>value</I><TT>
  601. pair, which is satisfied by keys with
  602. exactly that pair;
  603. or an attribute followed by a question mark,
  604. </TT><I>attribute</I><TT>?</TT><I>,
  605. which is satisfied by keys with some pair specifying
  606. the attribute.
  607. A key matches a query if every element in the list
  608. is satisfied.
  609. For instance, to select the APOP key in the previous example,
  610. an APOP client process might specify the query
  611. <DL><DT><DD><TT><PRE>
  612. server=x.y.com proto=apop
  613. </PRE></TT></DL>
  614. Internally,
  615. </I><TT>factotum</TT><I>'s
  616. APOP module would add the requirements of
  617. having
  618. </I><TT>user</TT><I>
  619. and
  620. </I><TT>!password</TT><I>
  621. attributes, forming the query
  622. <DL><DT><DD><TT><PRE>
  623. server=x.y.com proto=apop user? !password?
  624. </PRE></TT></DL>
  625. when searching for an appropriate key.
  626. </I><br>&#32;<br>
  627. <TT>Factotum</TT>
  628. modules expect keys to have some well-known attributes.
  629. For instance, the
  630. <TT>proto</TT>
  631. attribute specifies the protocol module
  632. responsible for using a particular key,
  633. and protocol modules may expect other well-known attributes
  634. (many expect keys to have
  635. <TT>!password</TT>
  636. attributes, for example).
  637. Additional attributes can be used as comments or for
  638. further discrimination without intervention by
  639. <TT>factotum</TT>;
  640. for example, the APOP and IMAP mail clients conventionally
  641. include a
  642. <TT>server</TT>
  643. attribute to select an appropriate key for authentication.
  644. <br>&#32;<br>
  645. Unlike in SDSI,
  646. keys in Plan 9 have no nested structure. This design
  647. keeps the representation simple and straightforward.
  648. If necessary, we could add a nested attribute
  649. or, in the manner of relational databases, an attribute that
  650. selects another tuple, but so far the simple design has been sufficient.
  651. <br>&#32;<br>
  652. A simple common structure for all keys makes them easy for users
  653. to administer,
  654. but the set of attributes and their interpretation is still
  655. protocol-specific and can be subtle.
  656. Users may still
  657. need to consult a manual to understand all details.
  658. Many attributes
  659. (<TT>proto</TT>,
  660. <TT>user</TT>,
  661. <TT>password</TT>,
  662. <TT>server</TT>)
  663. are self-explanatory and our short experience
  664. has not uncovered any particular difficulty in handling keys.
  665. Things
  666. will likely get messier, however,
  667. when we grapple with public
  668. keys and their myriad components.
  669. <H4>2.5 Protecting keys
  670. </H4>
  671. <br>&#32;<br>
  672. Secrets must be prevented from escaping
  673. <TT>factotum</TT>.
  674. There are a number of ways they could leak:
  675. another process might be able to debug the agent process, the
  676. agent might swap out to disk, or the process might willingly
  677. disclose the key.
  678. The last is the easiest to avoid:
  679. secret information in a key is marked
  680. as such, and
  681. whenever
  682. <TT>factotum</TT>
  683. prints keys or queries for new
  684. ones, it is careful to avoid displaying secret information.
  685. (The only exception to this is the
  686. ``plaintext password'' protocol, which consists
  687. of sending the values of the
  688. <TT>user</TT>
  689. and
  690. <TT>!password</TT>
  691. attributes.
  692. Only keys tagged with
  693. <TT>proto=pass</TT>
  694. can have their passwords disclosed by this mechanism.)
  695. <br>&#32;<br>
  696. Preventing the first two forms of leakage
  697. requires help from the kernel.
  698. In Plan 9, every process is
  699. represented by a directory in the
  700. <TT>/proc</TT>
  701. file system.
  702. Using the files in this directory,
  703. other processes could (with appropriate access permission) examine
  704. <TT>factotum</TT>'s
  705. memory and registers.
  706. <TT>Factotum</TT>
  707. is protected from processes of other users
  708. by the default access bits of its
  709. <TT>/proc</TT>
  710. directory.
  711. However, we'd also like to protect the
  712. agent from other processes owned by the same user,
  713. both to avoid honest mistakes and to prevent
  714. an unattended terminal being
  715. exploited to discover secret passwords.
  716. To do this, we added a control message to
  717. <TT>/proc</TT>
  718. called
  719. <TT>private</TT>.
  720. Once the
  721. <TT>factotum</TT>
  722. process has written
  723. <TT>private</TT>
  724. to its
  725. <TT>/proc/</TT><I>pid</I><TT>/ctl</TT><I>
  726. file, no process can access
  727. </I><TT>factotum</TT><I>'s
  728. memory
  729. through
  730. </I><TT>/proc</TT><I>.
  731. (Plan 9 has no other mechanism, such as
  732. </I><TT>/dev/kmem</TT><I>,
  733. for accessing a process's memory.)
  734. </I><br>&#32;<br>
  735. Similarly, the agent's address space should not be
  736. swapped out, to prevent discovering unencrypted
  737. keys on the swapping media.
  738. The
  739. <TT>noswap</TT>
  740. control message in
  741. <TT>/proc</TT>
  742. prevents this scenario.
  743. Neither
  744. <TT>private</TT>
  745. nor
  746. <TT>noswap</TT>
  747. is specific to
  748. <TT>factotum</TT>.
  749. User-level file servers such as
  750. <TT>dossrv</TT>,
  751. which interprets FAT file systems,
  752. could use
  753. <TT>noswap</TT>
  754. to keep their buffer caches from being
  755. swapped to disk.
  756. <br>&#32;<br>
  757. Despite our precautions, attackers might still
  758. find a way to gain access to a process running as the host
  759. owner on a machine.
  760. Although they could not directly
  761. access the keys, attackers could use the local
  762. <TT>factotum</TT>
  763. to perform authentications for them.
  764. In the case
  765. of some keys, for example those locking bank
  766. accounts, we want a way to disable or at least
  767. detect such access.
  768. That is the role of the
  769. <TT>confirm</TT>
  770. attribute in a key.
  771. Whenever a key with a
  772. <TT>confirm</TT>
  773. attribute is accessed, the local user must
  774. confirm use of the key via a local GUI.
  775. The next section describes the actual mechanism.
  776. <br>&#32;<br>
  777. We have not addressed leaks possible as a result of
  778. someone rebooting or resetting a machine running
  779. <TT>factotum</TT>.
  780. For example, someone could reset a machine
  781. and reboot it with a debugger instead of a kernel,
  782. allowing them to examine the contents of memory
  783. and find keys. We have not found a satisfactory
  784. solution to this problem.
  785. <H4>2.6 Factotum transactions
  786. </H4>
  787. <br>&#32;<br>
  788. External programs manage
  789. <TT>factotum</TT>'s
  790. internal key state
  791. through its file interface,
  792. writing textual
  793. <TT>key</TT>
  794. and
  795. <TT>delkey</TT>
  796. commands to the
  797. <TT>/mnt/factotum/ctl</TT>
  798. file.
  799. Both commands take a list of attributes as an argument.
  800. <TT>Key</TT>
  801. creates a key with the given attributes, replacing any
  802. extant key with an identical set of public attributes.
  803. <TT>Delkey</TT>
  804. deletes all keys that match the given set of attributes.
  805. Reading the
  806. <TT>ctl</TT>
  807. file returns a list of keys, one per line, displaying only public attributes.
  808. The following example illustrates these interactions.
  809. <DL><DT><DD><TT><PRE>
  810. % cd /mnt/factotum
  811. % ls -l
  812. -lrw------- gre gre 0 Jan 30 22:17 confirm
  813. --rw------- gre gre 0 Jan 30 22:17 ctl
  814. -lr-------- gre gre 0 Jan 30 22:17 log
  815. -lrw------- gre gre 0 Jan 30 22:17 needkey
  816. --r--r--r-- gre gre 0 Jan 30 22:17 proto
  817. --rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
  818. % cat &gt;ctl
  819. key dom=bell-labs.com proto=p9sk1 user=gre
  820. !password='don''t tell'
  821. key proto=apop server=x.y.com user=gre
  822. !password='bite me'
  823. ^D
  824. % cat ctl
  825. key dom=bell-labs.com proto=p9sk1 user=gre
  826. key proto=apop server=x.y.com user=gre
  827. % echo 'delkey proto=apop' &gt;ctl
  828. % cat ctl
  829. key dom=bell-labs.com proto=p9sk1 user=gre
  830. %
  831. </PRE></TT></DL>
  832. (A file with the
  833. <TT>l</TT>
  834. bit set can be opened by only one process at a time.)
  835. <br>&#32;<br>
  836. The heart of the interface is the
  837. <TT>rpc</TT>
  838. file.
  839. Programs authenticate with
  840. <TT>factotum</TT>
  841. by writing a request to the
  842. <TT>rpc</TT>
  843. file
  844. and reading back the reply; this sequence is called an RPC
  845. <I>transaction</I>.
  846. Requests and replies have the same format:
  847. a textual verb possibly followed by arguments,
  848. which may be textual or binary.
  849. The most common reply verb is
  850. <TT>ok</TT>,
  851. indicating success.
  852. An RPC session begins with a
  853. <TT>start</TT>
  854. transaction; the argument is a key query as described
  855. earlier.
  856. Once started, an RPC conversation usually consists of
  857. a sequence of
  858. <TT>read</TT>
  859. and
  860. <TT>write</TT>
  861. transactions.
  862. If the conversation is successful, an
  863. <TT>authinfo</TT>
  864. transaction will return information about
  865. the identities learned during the transaction.
  866. The
  867. <TT>attr</TT>
  868. transaction returns a list of attributes for the current
  869. conversation; the list includes any attributes given in
  870. the
  871. <TT>start</TT>
  872. query as well as any public attributes from keys being used.
  873. <br>&#32;<br>
  874. As an example of the
  875. <TT>rpc</TT>
  876. file in action, consider a mail client
  877. connecting to a mail server and authenticating using
  878. the POP3 protocol's APOP challenge-response command.
  879. n(11There are four programs involved: the mail client 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99, the client
  880. <TT>factotum</TT>
  881. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99, the mail server 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99, and the server
  882. <TT>factotum</TT>
  883. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
  884. All authentication computations are handled by the
  885. <TT>factotum</TT>
  886. processes.
  887. The mail programs' role is just to relay messages.
  888. <br>&#32;<br>
  889. At startup, the mail server at
  890. <TT>x.y.com</TT>
  891. begins an APOP conversation
  892. with its
  893. <TT>factotum</TT>
  894. to obtain the banner greeting, which
  895. includes a challenge:
  896. <DL><DT><DD><TT><PRE>
  897. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: start proto=apop role=server
  898. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok
  899. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: read
  900. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
  901. </PRE></TT></DL>
  902. Having obtained the challenge, the server greets the client:
  903. <DL><DT><DD><TT><PRE>
  904. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
  905. </PRE></TT></DL>
  906. The client then uses an APOP conversation with its
  907. <TT>factotum</TT>
  908. to obtain a response:
  909. <DL><DT><DD><TT><PRE>
  910. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: start proto=apop role=client
  911. server=x.y.com
  912. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok
  913. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: write +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
  914. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok
  915. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: read
  916. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok APOP gre &lt;I&gt;response&lt;/I&gt;
  917. </PRE></TT></DL>
  918. <TT>Factotum</TT>
  919. requires that
  920. <TT>start</TT>
  921. requests include a
  922. <TT>proto</TT>
  923. attribute, and the APOP module requires an additional
  924. <TT>role</TT>
  925. attribute, but the other attributes are optional and only
  926. restrict the key space.
  927. Before responding to the
  928. <TT>start</TT>
  929. transaction, the client
  930. <TT>factotum</TT>
  931. looks for a key to
  932. use for the rest of the conversation.
  933. Because of the arguments in the
  934. <TT>start</TT>
  935. request, the key must have public attributes
  936. <TT>proto=apop</TT>
  937. and
  938. <TT>server=x.y.com</TT>;
  939. as mentioned earlier,
  940. the APOP module additionally requires that the key have
  941. <TT>user</TT>
  942. and
  943. <TT>!password</TT>
  944. attributes.
  945. Now that the client has obtained a response
  946. from its
  947. <TT>factotum</TT>,
  948. it echoes that response to the server:
  949. <DL><DT><DD><TT><PRE>
  950. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: APOP gre &lt;I&gt;response&lt;/I&gt;
  951. </PRE></TT></DL>
  952. Similarly, the server passes this message to
  953. its
  954. <TT>factotum</TT>
  955. and obtains another to send back.
  956. <DL><DT><DD><TT><PRE>
  957. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: write APOP gre &lt;I&gt;response&lt;/I&gt;
  958. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok
  959. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: read
  960. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok +OK welcome
  961. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: +OK welcome
  962. </PRE></TT></DL>
  963. Now the authentication protocol is done, and
  964. the server can retrieve information
  965. about what the protocol established.
  966. <DL><DT><DD><TT><PRE>
  967. n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: authinfo
  968. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok client=gre
  969. capability=<I>capability</I>
  970. </PRE></TT></DL>
  971. The
  972. <TT>authinfo</TT>
  973. data is a list of
  974. <I>attr</I><TT>=</TT><I>value</I><TT>
  975. pairs, here a client user name and a capability.
  976. (Protocols that establish shared secrets or provide
  977. mutual authentication indicate this by adding
  978. appropriate
  979. </TT><I>attr</I><TT>=</TT><I>value</I><TT>
  980. pairs.)
  981. The capability can be used by the server to change its
  982. identity to that of the client, as described earlier.
  983. Once it has changed its identity, the server can access and serve
  984. the client's mailbox.
  985. </TT><br>&#32;<br>
  986. Two more files provide hooks for a graphical
  987. <TT>factotum</TT>
  988. control interface.
  989. The first,
  990. <TT>confirm</TT>,
  991. allows the user detailed control over the use of certain keys.
  992. If a key has a
  993. <TT>confirm=</TT>
  994. attribute, then the user must approve each use of the key.
  995. A separate program with a graphical interface reads from the
  996. <TT>confirm</TT>
  997. file to see when a confirmation is necessary.
  998. The read blocks until a key usage needs to be approved, whereupon
  999. it will return a line of the form
  1000. <DL><DT><DD><TT><PRE>
  1001. confirm tag=1 <I>attributes</I>
  1002. </PRE></TT></DL>
  1003. requesting permission to use the key with those public attributes.
  1004. The graphical interface then prompts the user for approval
  1005. and writes back
  1006. <DL><DT><DD><TT><PRE>
  1007. tag=1 answer=yes
  1008. </PRE></TT></DL>
  1009. (or
  1010. <TT>answer=no</TT>).
  1011. <br>&#32;<br>
  1012. The second file,
  1013. <TT>needkey</TT>,
  1014. diverts key requests.
  1015. In the APOP example, if a suitable key had not been found
  1016. during the
  1017. <TT>start</TT>
  1018. transaction,
  1019. <TT>factotum</TT>
  1020. would have indicated failure by
  1021. returning a response indicating
  1022. what key was needed:
  1023. <DL><DT><DD><TT><PRE>
  1024. n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: needkey proto=apop
  1025. server=x.y.com user? !password?
  1026. </PRE></TT></DL>
  1027. A typical client would then prompt the user for the desired
  1028. key information, create a new key via the
  1029. <TT>ctl</TT>
  1030. file, and then reissue the
  1031. <TT>start</TT>
  1032. request.
  1033. If the
  1034. <TT>needkey</TT>
  1035. file is open,
  1036. then instead of failing, the transaction
  1037. will block, and the next read from the
  1038. <TT>/mnt/factotum/needkey</TT>
  1039. file will return a line of the form
  1040. <DL><DT><DD><TT><PRE>
  1041. needkey tag=1 <I>attributes</I><I>
  1042. </PRE></TT></DL>
  1043. The graphical interface then prompts the user for the needed
  1044. key information, creates the key via the
  1045. </I><TT>ctl</TT><I>
  1046. file, and writes back
  1047. </I><TT>tag=1</TT><I>
  1048. to resume the transaction.
  1049. </I><br>&#32;<br>
  1050. The remaining files are informational and used for debugging.
  1051. The
  1052. <TT>proto</TT>
  1053. file contains a list of supported protocols (to see what protocols the
  1054. system supports,
  1055. <TT>cat</TT>
  1056. <TT>/mnt/factotum/proto</TT>),
  1057. and the
  1058. <TT>log</TT>
  1059. file contains a log of operations and debugging output
  1060. enabled by a
  1061. <TT>debug</TT>
  1062. control message.
  1063. <br>&#32;<br>
  1064. The next few sections explain how
  1065. <TT>factotum</TT>
  1066. is used by system services.
  1067. <H4>3 Authentication in 9P
  1068. </H4>
  1069. <br>&#32;<br>
  1070. Plan 9 uses a remote file access protocol, 9P
  1071. [Pike93],
  1072. to connect to resources such as the
  1073. file server and remote processes.
  1074. The original design for 9P included special messages at the start of a conversation
  1075. to authenticate the user.
  1076. Multiple users can share a single connection, such as when a CPU server
  1077. runs processes for many users connected to a single file server,
  1078. but each must authenticate separately.
  1079. The authentication protocol, similar to that of Kerberos
  1080. [Stei88],
  1081. used a sequence of messages passed between client, file server, and authentication
  1082. server to verify the identities of the user, calling machine, and serving machine.
  1083. One major drawback to the design was that the authentication method was defined by 9P
  1084. itself and could not be changed.
  1085. Moreover, there was no mechanism to relegate
  1086. authentication to an external (trusted) agent,
  1087. so a process implementing 9P needed, besides support for file service,
  1088. a substantial body of cryptographic code to implement a handful of startup messages
  1089. in the protocol.
  1090. <br>&#32;<br>
  1091. A recent redesign of 9P
  1092. addressed a number of file service issues outside the scope of this paper.
  1093. On issues of authentication, there were two goals:
  1094. first, to remove details about authentication from the
  1095. protocol itself; second, to allow an external program to execute the authentication
  1096. part of the protocol.
  1097. In particular, we wanted a way to quickly incorporate
  1098. ideas found in other systems such as SFS
  1099. [Mazi99].
  1100. <br>&#32;<br>
  1101. Since 9P is a file service protocol, the solution involved creating a new type of file
  1102. to be served: an
  1103. <I>authentication</I>
  1104. <I>file</I>.
  1105. Connections to a 9P service begin in a state that
  1106. allows no general file access but permits the client
  1107. to open an authentication file
  1108. by sending a special message, generated by the new
  1109. <TT>fauth</TT>
  1110. system call:
  1111. <DL><DT><DD><TT><PRE>
  1112. afd = fauth(int fd, char *servicename);
  1113. </PRE></TT></DL>
  1114. Here
  1115. <TT>fd</TT>
  1116. is the user's file descriptor for the established network connection to the 9P server
  1117. and
  1118. <TT>servicename</TT>
  1119. is the name of the desired service offered on that server, typically the file subsystem
  1120. to be accessed.
  1121. The returned file descriptor,
  1122. <TT>afd</TT>,
  1123. is a unique handle representing the authentication file
  1124. created for this connection to authenticate to
  1125. this service; it is analogous to a capability.
  1126. The authentication file represented by
  1127. <TT>afd</TT>
  1128. is not otherwise addressable on the server, such as through
  1129. the file name hierarchy.
  1130. In all other respects, it behaves like a regular file;
  1131. most important, it accepts standard read and write operations.
  1132. <br>&#32;<br>
  1133. To prove its identity, the user process (via
  1134. <TT>factotum</TT>)
  1135. executes the authentication protocol,
  1136. described in the next section of this paper,
  1137. over the
  1138. <TT>afd</TT>
  1139. file descriptor with ordinary reads and writes.
  1140. When client and server have successfully negotiated, the authentication file
  1141. changes state so it can be used as evidence of authority in
  1142. <TT>mount</TT>.
  1143. <br>&#32;<br>
  1144. Once identity is established, the process presents the (now verified)
  1145. <TT>afd</TT>
  1146. as proof of identity to the
  1147. <TT>mount</TT>
  1148. system call:
  1149. <DL><DT><DD><TT><PRE>
  1150. mount(int fd, int afd, char *mountpoint,
  1151. int flag, char *servicename)
  1152. </PRE></TT></DL>
  1153. If the
  1154. <TT>mount</TT>
  1155. succeeds, the user now
  1156. has appropriate permissions for the file hierarchy made
  1157. visible at the mount point.
  1158. <br>&#32;<br>
  1159. This sequence of events has several advantages.
  1160. First, the actual authentication protocol is implemented using regular reads and writes,
  1161. not special 9P messages, so
  1162. they can be processed, forwarded, proxied, and so on by
  1163. any 9P agent without special arrangement.
  1164. Second, the business of negotiating the authentication by reading and writing the
  1165. authentication file can be delegated to an outside agent, in particular
  1166. <TT>factotum</TT>;
  1167. the programs that implement the client and server ends of a 9P conversation need
  1168. no authentication or cryptographic code.
  1169. Third,
  1170. since the authentication protocol is not defined by 9P itself, it is easy to change and
  1171. can even be negotiated dynamically.
  1172. Finally, since
  1173. <TT>afd</TT>
  1174. acts like a capability, it can be treated like one:
  1175. handed to another process to give it special permissions;
  1176. kept around for later use when authentication is again required;
  1177. or closed to make sure no other process can use it.
  1178. <br>&#32;<br>
  1179. All these advantages stem from moving the authentication negotiation into
  1180. reads and writes on a separate file.
  1181. As is often the case in Plan 9,
  1182. making a resource (here authentication) accessible with a file-like interface
  1183. reduces
  1184. <I>a</I>
  1185. <I>priori</I>
  1186. the need for special interfaces.
  1187. <br>&#32;<br>
  1188. <H4>3.1 Plan 9 shared key protocol
  1189. </H4>
  1190. <br>&#32;<br>
  1191. In addition to the various standard protocols supported by
  1192. <TT>factotum</TT>,
  1193. we use a shared key protocol for native
  1194. Plan 9 authentication.
  1195. This protocol provides backward compatibility with
  1196. older versions of the system. One reason for the new
  1197. architecture is to let us replace such protocols
  1198. in the near future with more cryptographically secure ones.
  1199. <br>&#32;<br>
  1200. <I>P9sk1</I>
  1201. is a shared key protocol that uses tickets much like those
  1202. in the original Kerberos.
  1203. The difference is that we've
  1204. replaced the expiration time in Kerberos tickets with
  1205. a random nonce parameter and a counter.
  1206. We summarize it here:
  1207. <DL><DT><DD><TT><PRE>
  1208. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  1209. n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99
  1210. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;: &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,n(99
  1211. n(11 11&lt;I&gt;factotum&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  1212. n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
  1213. n(11 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11}n(99
  1214. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
  1215. n(11 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
  1216. n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
  1217. </PRE></TT></DL>
  1218. n(11(Here 11&lt;I&gt;K&lt;/I&gt;{&lt;I&gt;x&lt;/I&gt;}n(99 indicates 11&lt;I&gt;x&lt;/I&gt;n(99 encrypted with
  1219. n(11DES key 11&lt;I&gt;K&lt;/I&gt;n(99.)
  1220. The first two messages exchange nonces and server identification.
  1221. After this initial exchange, the client contacts the authentication
  1222. server to obtain a pair of encrypted tickets, one encrypted with
  1223. the client key and one with the server key.
  1224. The client relays the server ticket to the server.
  1225. The server believes that the ticket is new
  1226. because it contains
  1227. n(1111&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99
  1228. and that the ticket is from the authentication
  1229. n(11server because it is encrypted in the server key 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
  1230. The ticket is basically a statement from the authentication
  1231. n(11server that now 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99 and 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99 share a
  1232. n(11secret 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11n(99.
  1233. n(11The authenticator 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
  1234. n(11convinces the server that the client knows 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11n(99 and thus
  1235. n(11must be 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99.
  1236. n(11Similarly, authenticator 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
  1237. n(11convinces the client that the server knows 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11n(99 and thus
  1238. n(11must be 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
  1239. Tickets can be reused, without contacting the authentication
  1240. server again, by incrementing the counter before each
  1241. authenticator is generated.
  1242. <br>&#32;<br>
  1243. In the future we hope to introduce a public key version of
  1244. p9sk1,
  1245. which would allow authentication even
  1246. when the authentication server is not available.
  1247. <H4>3.2 The authentication server
  1248. </H4>
  1249. <br>&#32;<br>
  1250. Each Plan 9 security domain has an authentication server (AS)
  1251. that all users trust to keep the complete set of shared keys.
  1252. It also offers services for users and administrators to manage the
  1253. keys, create and disable accounts, and so on.
  1254. It typically runs on
  1255. a standalone machine with few other services.
  1256. The AS comprises two services,
  1257. <TT>keyfs</TT>
  1258. and
  1259. <TT>authsrv</TT>.
  1260. <br>&#32;<br>
  1261. <TT>Keyfs</TT>
  1262. is a user-level file system that manages an
  1263. encrypted database of user accounts.
  1264. Each account is represented by a directory containing the
  1265. files
  1266. <TT>key</TT>,
  1267. containing the Plan 9 key for p9sk1;
  1268. <TT>secret</TT>
  1269. for the challenge/response protocols (APOP, VNC, CHAP, MSCHAP,
  1270. CRAM);
  1271. <TT>log</TT>
  1272. for authentication outcomes;
  1273. <TT>expire</TT>
  1274. for an expiration time; and
  1275. <TT>status</TT>.
  1276. If the expiration time passes,
  1277. if the number of successive failed authentications
  1278. exceeds 50, or if
  1279. <TT>disabled</TT>
  1280. is written to the status file,
  1281. any attempt to access the
  1282. <TT>key</TT>
  1283. or
  1284. <TT>secret</TT>
  1285. files will fail.
  1286. <br>&#32;<br>
  1287. <TT>Authsrv</TT>
  1288. is a network service that brokers shared key authentications
  1289. for the protocols p9sk1, APOP, VNC, CHAP, MSCHAP,
  1290. and CRAM. Remote users can also call
  1291. <TT>authsrv</TT>
  1292. to change their passwords.
  1293. <br>&#32;<br>
  1294. The
  1295. p9sk1
  1296. protocol was described in the previous
  1297. section.
  1298. The challenge/response protocols differ
  1299. in detail but all follow the general structure:
  1300. <DL><DT><DD><TT><PRE>
  1301. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  1302. n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99
  1303. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;: &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,n(99
  1304. n(11 11&lt;I&gt;hostid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  1305. n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
  1306. n(11 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11}n(99
  1307. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
  1308. n(11 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11}n(99
  1309. n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11}n(99
  1310. </PRE></TT></DL>
  1311. The password protocol is:
  1312. <DL><DT><DD><TT><PRE>
  1313. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;: &lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
  1314. n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;c&lt;/I&gt;11{&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11}n(99
  1315. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;: &lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;password&lt;/I&gt;&lt;I&gt;old&lt;/I&gt;11,&lt;I&gt;password&lt;/I&gt;&lt;I&gt;new&lt;/I&gt;11}n(99
  1316. n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;OK&lt;/I&gt;n(99
  1317. </PRE></TT></DL>
  1318. To avoid replay attacks, the pre-encryption
  1319. clear text for each of the protocols (as well as for p9sk1) includes
  1320. a tag indicating the encryption's role in the
  1321. protocol. We elided them in these outlines.
  1322. <H4>3.3 Protocol negotiation
  1323. </H4>
  1324. <br>&#32;<br>
  1325. Rather than require particular protocols for particular services,
  1326. we implemented a negotiation metaprotocol,
  1327. <I>p9any</I>,
  1328. which chooses the actual authentication protocol to use.
  1329. P9any
  1330. is used now by all native services on Plan 9.
  1331. <br>&#32;<br>
  1332. The metaprotocol is simple. The callee sends a
  1333. null-terminated string of the form:
  1334. <DL><DT><DD><TT><PRE>
  1335. n(11v.11&lt;I&gt;n&lt;/I&gt;n(99 11&lt;I&gt;proto&lt;/I&gt;111n(99@11&lt;I&gt;domain&lt;/I&gt;111n(99 11&lt;I&gt;proto&lt;/I&gt;211n(99@11&lt;I&gt;domain&lt;/I&gt;211n(99 ...
  1336. </PRE></TT></DL>
  1337. where
  1338. <I>n</I>
  1339. n(11is a decimal version number, 11&lt;I&gt;proto&lt;/I&gt;&lt;I&gt;k&lt;/I&gt;11n(99
  1340. is the name of a protocol for which the
  1341. <TT>factotum</TT>
  1342. n(11has a key, and 11&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;k&lt;/I&gt;11n(99
  1343. is the name of the domain in which the key is
  1344. valid.
  1345. The caller then responds
  1346. <DL><DT><DD><TT><PRE>
  1347. <I>proto</I>@<I>domain</I>
  1348. </PRE></TT></DL>
  1349. indicating its choice.
  1350. Finally the callee responds
  1351. <DL><DT><DD><TT><PRE>
  1352. OK
  1353. </PRE></TT></DL>
  1354. Any other string indicates failure.
  1355. At this point the chosen protocol commences.
  1356. The final fixed-length reply is used to make it easy to
  1357. delimit the I/O stream should the chosen protocol
  1358. require the caller rather than the callee to send the first message.
  1359. <br>&#32;<br>
  1360. With this negotiation metaprotocol, the underlying
  1361. authentication protocols used for Plan 9 services
  1362. can be changed under any application just
  1363. by changing the keys known by the
  1364. <TT>factotum</TT>
  1365. agents at each end.
  1366. <br>&#32;<br>
  1367. P9any is vulnerable to man in the middle attacks
  1368. to the extent that the attacker may constrain the
  1369. possible choices by changing the stream. However,
  1370. we believe this is acceptable since the attacker
  1371. cannot force either side to choose algorithms
  1372. that it is unwilling to use.
  1373. <H4>4 Library Interface to Factotum
  1374. </H4>
  1375. <br>&#32;<br>
  1376. Although programs can access
  1377. <TT>factotum</TT>'s
  1378. services through its file system interface,
  1379. it is more common to use a C library that
  1380. packages the interaction.
  1381. There are a number of routines in the library,
  1382. not all of which are relevant here, but a few
  1383. examples should give their flavor.
  1384. <br>&#32;<br>
  1385. First, consider the problem of mounting a remote file server using 9P.
  1386. An earlier discussion showed how the
  1387. <TT>fauth</TT>
  1388. and
  1389. <TT>mount</TT>
  1390. system calls use an authentication file,
  1391. <TT>afd</TT>,
  1392. as a capability,
  1393. but not how
  1394. <TT>factotum</TT>
  1395. manages
  1396. <TT>afd</TT>.
  1397. The library contains a routine,
  1398. <TT>amount</TT>
  1399. (authenticated mount), that is used by most programs in preference to
  1400. the raw
  1401. <TT>fauth</TT>
  1402. and
  1403. <TT>mount</TT>
  1404. calls.
  1405. <TT>Amount</TT>
  1406. engages
  1407. <TT>factotum</TT>
  1408. to validate
  1409. <TT>afd</TT>;
  1410. here is the complete code:
  1411. <DL><DT><DD><TT><PRE>
  1412. int
  1413. amount(int fd, char *mntpt,
  1414. int flags, char *aname)
  1415. {
  1416. int afd, ret;
  1417. AuthInfo *ai;
  1418. afd = fauth(fd, aname);
  1419. if(afd &gt;= 0){
  1420. ai = auth_proxy(afd, amount_getkey,
  1421. "proto=p9any role=client");
  1422. if(ai != NULL)
  1423. auth_freeAI(ai);
  1424. }
  1425. ret = mount(fd, afd, mntpt,
  1426. flags, aname);
  1427. if(afd &gt;= 0)
  1428. close(afd);
  1429. return ret;
  1430. }
  1431. </PRE></TT></DL>
  1432. where parameter
  1433. <TT>fd</TT>
  1434. is a file descriptor returned by
  1435. <TT>open</TT>
  1436. or
  1437. <TT>dial</TT>
  1438. for a new connection to a file server.
  1439. The conversation with
  1440. <TT>factotum</TT>
  1441. occurs in the call to
  1442. <TT>auth_proxy</TT>,
  1443. which specifies, as a key query,
  1444. which authentication protocol to use
  1445. (here the metaprotocol
  1446. <TT>p9any</TT>)
  1447. and the role being played
  1448. (<TT>client</TT>).
  1449. <TT>Auth_proxy</TT>
  1450. will read and write the
  1451. <TT>factotum</TT>
  1452. files, and the authentication file descriptor
  1453. <TT>afd</TT>,
  1454. to validate the user's right to access the service.
  1455. If the call is successful, any auxiliary data, held in an
  1456. <TT>AuthInfo</TT>
  1457. structure, is freed.
  1458. In any case, the
  1459. <TT>mount</TT>
  1460. is then called with the (perhaps validated)
  1461. <TT>afd.</TT>
  1462. A 9P server can cause the
  1463. <TT>fauth</TT>
  1464. system call to fail, as an indication that authentication is
  1465. not required to access the service.
  1466. <br>&#32;<br>
  1467. The second argument to
  1468. <TT>auth_proxy</TT>
  1469. is a function, here
  1470. <TT>amount_getkey</TT>,
  1471. to be called if secret information such as a password or
  1472. response to a challenge is required as part of the authentication.
  1473. This function, of course, will provide this data to
  1474. <TT>factotum</TT>
  1475. as a
  1476. <TT>key</TT>
  1477. message on the
  1478. <TT>/mnt/factotum/ctl</TT>
  1479. file.
  1480. <br>&#32;<br>
  1481. Although the final argument to
  1482. <TT>auth_proxy</TT>
  1483. in this example is a simple string, in general
  1484. it can be a formatted-print specifier in the manner of
  1485. <TT>printf</TT>,
  1486. to enable the construction of more elaborate key queries.
  1487. <br>&#32;<br>
  1488. As another example, consider the Plan 9
  1489. <TT>cpu</TT>
  1490. service, which exports local devices to a shell process on
  1491. a remote machine, typically
  1492. to connect the local screen and keyboard to a more powerful computer.
  1493. At heart,
  1494. <TT>cpu</TT>
  1495. is a superset of a service called
  1496. <TT>exportfs</TT>
  1497. [Pike93],
  1498. which allows one machine to see an arbitrary portion of the file name space
  1499. of another machine, such as to
  1500. export the network device to another machine
  1501. for gatewaying.
  1502. However,
  1503. <TT>cpu</TT>
  1504. is not just
  1505. <TT>exportfs</TT>
  1506. because it also delivers signals such as interrupt
  1507. and negotiates the initial environment
  1508. for the remote shell.
  1509. <br>&#32;<br>
  1510. To authenticate an instance of
  1511. <TT>cpu</TT>
  1512. requires
  1513. <TT>factotum</TT>
  1514. processes on both ends: the local, client
  1515. end running as the user on a terminal
  1516. and the remote, server
  1517. end running as the host owner of the server machine.
  1518. Here is schematic code for the two ends:
  1519. <DL><DT><DD><TT><PRE>
  1520. /* client */
  1521. int
  1522. p9auth(int fd)
  1523. {
  1524. AuthInfo *ai;
  1525. ai = auth_proxy(fd, auth_getkey,
  1526. "proto=p9any role=client");
  1527. if(ai == NULL)
  1528. return -1;
  1529. /* start cpu protocol here */
  1530. }
  1531. /* server */
  1532. int
  1533. srvp9auth(int fd, char *user)
  1534. {
  1535. AuthInfo *ai;
  1536. ai = auth_proxy(fd, NULL,
  1537. "proto=p9any role=server");
  1538. if(ai == NULL)
  1539. return -1;
  1540. /* set user id for server process */
  1541. if(auth_chuid(ai, NULL) &lt; 0)
  1542. return -1;
  1543. /* start cpu protocol here */
  1544. }
  1545. </PRE></TT></DL>
  1546. <TT>Auth_chuid</TT>
  1547. encapsulates the negotiation to change a user id using the
  1548. <TT>caphash</TT>
  1549. and
  1550. <TT>capuse</TT>
  1551. files of the (server) kernel.
  1552. Note that although the client process may ask the user for new keys, using
  1553. <TT>auth_getkey</TT>,
  1554. the server machine, presumably a shared machine with a pseudo-user for
  1555. the host owner, sets the key-getting function to
  1556. <TT>NULL</TT>.
  1557. <H4>5 Secure Store
  1558. </H4>
  1559. <br>&#32;<br>
  1560. <TT>Factotum</TT>
  1561. keeps its keys in volatile memory, which must somehow be
  1562. initialized at boot time.
  1563. Therefore,
  1564. <TT>factotum</TT>
  1565. must be
  1566. supplemented by a persistent store, perhaps
  1567. a floppy disk containing a key file of commands to be copied into
  1568. <TT>/mnt/factotum/ctl</TT>
  1569. during bootstrap.
  1570. But removable media are a nuisance to carry and
  1571. are vulnerable to theft.
  1572. Keys could be stored encrypted on a shared file system, but
  1573. only if those keys are not necessary for authenticating to
  1574. the file system in the first place.
  1575. Even if the keys are encrypted under a user
  1576. password, a thief might well succeed with a dictionary attack.
  1577. Other risks of local storage are loss of the contents
  1578. through mechanical mishap or dead batteries.
  1579. Thus for convenience and
  1580. safety we provide a
  1581. <TT>secstore</TT>
  1582. (secure store) server in the network to hold each user's permanent list of keys, a
  1583. <I>key</I>
  1584. <I>file</I>.
  1585. <br>&#32;<br>
  1586. <TT>Secstore</TT>
  1587. is a file server for encrypted data,
  1588. used only during bootstrapping.
  1589. It must provide strong
  1590. authentication and resistance to passive and active protocol attacks
  1591. while assuming nothing more from the client than a password.
  1592. Once
  1593. <TT>factotum</TT>
  1594. has loaded the key file, further encrypted or authenticated
  1595. file storage can be accomplished by standard mechanisms.
  1596. <br><img src="-.19111514.gif"><br>
  1597. <br>&#32;<br>
  1598. The cryptographic technology that enables
  1599. <TT>secstore</TT>
  1600. is a form of encrypted
  1601. key exchange
  1602. called PAK
  1603. [Boyk00],
  1604. analogous to
  1605. EKE
  1606. [Bell93],
  1607. SRP
  1608. [Wu98],
  1609. or
  1610. SPEKE
  1611. [Jabl].
  1612. PAK was chosen
  1613. because it comes with a proof of equivalence in strength to
  1614. Diffie-Hellman; subtle flaws in some earlier encrypted key exchange
  1615. protocols and implementations have encouraged us to take special care.
  1616. In outline, the PAK protocol is:
  1617. <DL><DT><DD><TT><PRE>
  1618. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;C&lt;/I&gt;,&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;x&lt;/I&gt;11&lt;I&gt;H&lt;/I&gt;n(99
  1619. n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;S&lt;/I&gt;,&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;y&lt;/I&gt;11,&lt;I&gt;hash&lt;/I&gt;(&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;xy&lt;/I&gt;11,&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;)n(99
  1620. n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;hash&lt;/I&gt;(&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;xy&lt;/I&gt;11,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;C&lt;/I&gt;)n(99
  1621. </PRE></TT></DL>
  1622. n(11where 11&lt;I&gt;H&lt;/I&gt;n(99 is a preshared secret between client 11&lt;I&gt;C&lt;/I&gt;n(99 and server 11&lt;I&gt;S&lt;/I&gt;n(99.
  1623. There are several variants of PAK, all presented in papers
  1624. mainly concerned with proofs of cryptographic properties.
  1625. To aid implementers, we have distilled a description of the specific
  1626. version we use into an Appendix to this paper.
  1627. The Plan 9 open source license provides for use of Lucent's
  1628. encrypted key exchange patents in this context.
  1629. <br>&#32;<br>
  1630. As a further layer of defense against password theft,
  1631. n(11we provide (within the encrypted channel 11&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;n(99)
  1632. information that is validated at a RADIUS server,
  1633. such as the digits from a hardware token
  1634. [RFC2138].
  1635. This provides two-factor authentication, which potentially
  1636. requires tricking two independent administrators in any attack by
  1637. social engineering.
  1638. <br>&#32;<br>
  1639. The key file stored on the server is encrypted with AES (Rijndael) using CBC
  1640. with a 10-byte initialization vector and trailing authentication padding.
  1641. All this is invisible to the user of
  1642. <TT>secstore</TT>.
  1643. For that matter, it is invisible to the
  1644. <TT>secstore</TT>
  1645. server as well;
  1646. if the AES Modes of Operation are standardized and a new encryption format
  1647. designed, it can be implemented by a client without change to the server.
  1648. The
  1649. <TT>secstore</TT>
  1650. is deliberately not backed up; the user is expected to
  1651. use more than one
  1652. <TT>secstore</TT>
  1653. or save the key file on removable media
  1654. and lock it away.
  1655. n(11The user's password is hashed to create the 11&lt;I&gt;H&lt;/I&gt;n(99 used
  1656. in the PAK protocol; a different hash of the password is used as
  1657. the file encryption key.
  1658. Finally, there is a command (inside the authenticated,
  1659. encrypted channel between client and
  1660. <TT>secstore</TT>)
  1661. to change passwords by sending
  1662. n(11a new 11&lt;I&gt;H&lt;/I&gt;n(99;
  1663. for consistency, the client process must at the same time fetch and re-encrypt all files.
  1664. <br>&#32;<br>
  1665. When
  1666. <TT>factotum</TT>
  1667. starts, it dials the local
  1668. <TT>secstore</TT>
  1669. and checks whether the user has an account.
  1670. If so,
  1671. it prompts for the user's
  1672. <TT>secstore</TT>
  1673. password and fetches the key file.
  1674. The PAK protocol
  1675. ensures mutual authentication and prevents dictionary attacks on the password
  1676. by passive wiretappers or active intermediaries.
  1677. Passwords saved in
  1678. the key file can be long random strings suitable for
  1679. simpler challenge/response authentication protocols.
  1680. Thus the user need only remember
  1681. a single, weaker password to enable strong, ``single sign on'' authentication to
  1682. unchanged legacy applications scattered across multiple authentication domains.
  1683. <H4>6 Transport Layer Security
  1684. </H4>
  1685. <br>&#32;<br>
  1686. Since the Plan 9 operating system is designed for use in network elements
  1687. that must withstand direct attack, unguarded by firewall or VPN, we seek
  1688. to ensure that all applications use channels with appropriate mutual
  1689. authentication and encryption.
  1690. A principal tool for this is TLS 1.0
  1691. [RFC2246].
  1692. (TLS 1.0 is nearly the same as SSL 3.0,
  1693. and our software is designed to interoperate
  1694. with implementations of either standard.)
  1695. <br>&#32;<br>
  1696. TLS defines a record layer protocol for message integrity and privacy
  1697. through the use of message digesting and encryption with shared secrets.
  1698. We implement this service as a kernel device, though it could
  1699. be performed at slightly higher cost by invoking a separate program.
  1700. The library interface to the TLS kernel device is:
  1701. <DL><DT><DD><TT><PRE>
  1702. int pushtls(int fd, char *hashalg,
  1703. char *cryptalg, int isclient,
  1704. char *secret, char *dir);
  1705. </PRE></TT></DL>
  1706. Given a file descriptor, the names of message digest and
  1707. encryption algorithms, and the shared secret,
  1708. <TT>pushtls</TT>
  1709. returns a new file descriptor for the encrypted connection.
  1710. (The final argument
  1711. <TT>dir</TT>
  1712. receives the name of the directory in the TLS device that
  1713. is associated with the new connection.)
  1714. The function is named by analogy with the ``push'' operation
  1715. supported by the stream I/O system of Research Unix and the
  1716. first two editions of Plan 9.
  1717. Because adding encryption is as simple as replacing one
  1718. file descriptor with another, adding encryption to a particular
  1719. network service is usually trivial.
  1720. <br>&#32;<br>
  1721. The Plan 9 shared key authentication protocols establish a shared 56-bit secret
  1722. as a side effect.
  1723. Native Plan 9 network services such as
  1724. <TT>cpu</TT>
  1725. and
  1726. <TT>exportfs</TT>
  1727. use these protocols for authentication and then invoke
  1728. <TT>pushtls</TT>
  1729. with the shared secret.
  1730. <br>&#32;<br>
  1731. Above the record layer, TLS specifies a handshake protocol using public keys
  1732. to establish the session secret.
  1733. This protocol is widely used with HTTP and IMAP4
  1734. to provide server authentication, though with client certificates it could provide
  1735. mutual authentication. The library function
  1736. <DL><DT><DD><TT><PRE>
  1737. int tlsClient(int fd, TLSconn *conn)
  1738. </PRE></TT></DL>
  1739. handles the initial handshake and returns the result of
  1740. <TT>pushtls</TT>.
  1741. On return, it fills the
  1742. <TT>conn</TT>
  1743. structure with the session ID used
  1744. and the X.509 certificate presented by the
  1745. server, but makes no effort to verify the certificate.
  1746. Although the original design intent of X.509 certificates expected
  1747. that they would be used with a Public Key Infrastructure,
  1748. reliable deployment has been so long delayed and problematic
  1749. that we have adopted the simpler policy of just using the
  1750. X.509 certificate as a representation of the public key,
  1751. depending on a locally-administered directory of SHA1 thumbprints
  1752. to allow applications to decide which public keys to trust
  1753. for which purposes.
  1754. <H4>7 Related Work and Discussion
  1755. </H4>
  1756. <br>&#32;<br>
  1757. Kerberos, one of the earliest distributed authentication
  1758. systems, keeps a set of authentication tickets in a temporary file called
  1759. a ticket cache. The ticket cache is protected by Unix file permissions.
  1760. An environment variable containing the file name of the ticket cache
  1761. allows for different ticket caches in different simultaneous login sessions.
  1762. A user logs in by typing his or her Kerberos password.
  1763. The login program uses the Kerberos password to obtain a temporary
  1764. ticket-granting ticket from the authentication server, initializes the
  1765. ticket cache with the ticket-granting ticket, and then forgets the password.
  1766. Other applications can use the ticket-granting ticket to sign tickets
  1767. for themselves on behalf of the user during the login session.
  1768. The ticket cache is removed when the user logs out
  1769. [Stei88].
  1770. The ticket cache relieves the user from typing a password
  1771. every time authentication is needed.
  1772. <br>&#32;<br>
  1773. The secure shell SSH develops this idea further, replacing the
  1774. temporary file with a named Unix domain socket connected to
  1775. a user-level program, called an agent.
  1776. Once the SSH agent is started and initialized with one or
  1777. more RSA private keys, SSH clients can employ it
  1778. to perform RSA authentications on their behalf.
  1779. In the absence of an agent, SSH typically uses RSA keys
  1780. read from encrypted disk files or uses passphrase-based
  1781. authentication, both of which would require prompting the user
  1782. for a passphrase whenever authentication is needed
  1783. [Ylon96].
  1784. The self-certifying file system SFS uses a similar agent
  1785. [Kami00],
  1786. not only for moderating the use of client authentication keys
  1787. but also for verifying server public keys
  1788. [Mazi99].
  1789. <br>&#32;<br>
  1790. <TT>Factotum</TT>
  1791. is a logical continuation of this evolution,
  1792. replacing the program-specific SSH or SFS agents with
  1793. a general agent capable of serving a wide variety of programs.
  1794. Having one agent for all programs removes the need
  1795. to have one agent for each program.
  1796. It also allows the programs themselves to be protocol-agnostic,
  1797. so that, for example, one could build an SSH workalike
  1798. capable of using any protocol supported by
  1799. <TT>factotum</TT>,
  1800. without that program knowing anything about the protocols.
  1801. Traditionally each program needs to implement each
  1802. n(11authentication protocol for itself, an 11&lt;I&gt;O&lt;/I&gt;(&lt;I&gt;n&lt;/I&gt;^211)n(99 coding
  1803. problem that
  1804. <TT>factotum</TT>
  1805. n(11reduces to 11&lt;I&gt;O&lt;/I&gt;(&lt;I&gt;n&lt;/I&gt;)n(99.
  1806. <br>&#32;<br>
  1807. Previous work on agents has concentrated on their use by clients
  1808. authenticating to servers.
  1809. Looking in the other direction, Sun Microsystem's
  1810. pluggable authentication module (PAM) is one
  1811. of the earliest attempts to
  1812. provide a general authentication mechanism for Unix-like
  1813. operating systems
  1814. [Sama96].
  1815. Without a central authority like PAM, system policy is tied
  1816. up in the various implementations of network services.
  1817. For example, on a typical Unix, if a system administrator
  1818. decides not to allow plaintext passwords for authentication,
  1819. the configuration files for a half dozen different servers &#173;
  1820. <TT>rlogind</TT>,
  1821. <TT>telnetd</TT>,
  1822. <TT>ftpd</TT>,
  1823. <TT>sshd</TT>,
  1824. and so on &#173;
  1825. need to be edited.
  1826. PAM solves this problem by hiding the details of a given
  1827. authentication mechanism behind a common library interface.
  1828. Directed by a system-wide configuration file,
  1829. an application selects a particular authentication mechanism
  1830. by dynamically loading the appropriate shared library.
  1831. PAM is widely used on Sun's Solaris and some Linux distributions.
  1832. <br>&#32;<br>
  1833. <TT>Factotum</TT>
  1834. achieves the same goals
  1835. using the agent approach.
  1836. <TT>Factotum</TT>
  1837. is the only process that needs to create
  1838. capabilities, so all the network servers can run as
  1839. untrusted users (e.g.,
  1840. Plan 9's
  1841. <TT>none</TT>
  1842. or Unix's
  1843. <TT>nobody</TT>),
  1844. which greatly reduces the harm done if a server is buggy
  1845. and is compromised.
  1846. In fact, if
  1847. <TT>factotum</TT>
  1848. were implemented on Unix along with
  1849. an analogue to the Plan 9 capability device, venerable
  1850. programs like
  1851. <TT>su</TT>
  1852. and
  1853. <TT>login</TT>
  1854. would no longer need to be installed ``setuid root.''
  1855. <br>&#32;<br>
  1856. Several other systems, such as Password Safe [Schn],
  1857. store multiple passwords in an encrypted file,
  1858. so that the user only needs to remember one password.
  1859. Our
  1860. <TT>secstore</TT>
  1861. solution differs from these by placing the storage in
  1862. a hardened location in the network, so that the encrypted file is
  1863. less liable to be stolen for offline dictionary attack and so that
  1864. it is available even when a user has several computers.
  1865. In contrast, Microsoft's Passport system
  1866. [Micr]
  1867. keeps credentials in
  1868. the network, but centralized at one extremely-high-value target.
  1869. The important feature of Passport, setting up trust relationships
  1870. with e-merchants, is outside our scope.
  1871. The
  1872. <TT>secstore</TT>
  1873. architecture is almost identical to
  1874. Perlman and Kaufman's
  1875. [Perl99]
  1876. but with newer EKE technology.
  1877. Like them, we chose to defend mainly against outside attacks
  1878. on
  1879. <TT>secstore</TT>;
  1880. if additional defense of the files on the server
  1881. itself is desired, one can use distributed techniques
  1882. [Ford00].
  1883. <br>&#32;<br>
  1884. We made a conscious choice of placing encryption, message integrity,
  1885. and key management at the application layer
  1886. (TLS, just above layer 4) rather than at layer 3, as in IPsec.
  1887. This leads to a simpler structure for the network stack, easier
  1888. integration with applications and, most important, easier network
  1889. administration since we can recognize which applications are misbehaving
  1890. based on TCP port numbers. TLS does suffer (relative to IPsec) from
  1891. the possibility of forged TCP Reset, but we feel that this is adequately
  1892. dealt with by randomized TCP sequence numbers.
  1893. In contrast with other TLS libraries, Plan 9 does not
  1894. require the application to change
  1895. <TT>write</TT>
  1896. calls to
  1897. <TT>sslwrite</TT>
  1898. but simply to add a few lines of code at startup
  1899. [Resc01].
  1900. <H4>8 Conclusion
  1901. </H4>
  1902. <br>&#32;<br>
  1903. Writing safe code is difficult.
  1904. Stack attacks,
  1905. mistakes in logic, and bugs in compilers and operating systems
  1906. can each make it possible for an attacker
  1907. to subvert the intended execution sequence of a
  1908. service.
  1909. If the server process has the privileges
  1910. of a powerful user, such as
  1911. <TT>root</TT>
  1912. on Unix, then so does the attacker.
  1913. <TT>Factotum</TT>
  1914. allows us
  1915. to constrain the privileged execution to a single
  1916. process whose core is a few thousand lines of code.
  1917. Verifying such a process, both through manual and automatic means,
  1918. is much easier and less error prone
  1919. than requiring it of all servers.
  1920. <br>&#32;<br>
  1921. An implementation of these ideas is in Plan 9 from Bell Labs, Fourth Edition,
  1922. freely available from <TT>http://plan9.bell-labs.com/plan9</TT>.
  1923. <H4>Acknowledgments
  1924. </H4>
  1925. <br>&#32;<br>
  1926. William Josephson contributed to the implementation of password changing in
  1927. <TT>secstore</TT>.
  1928. We thank Phil MacKenzie and Mart&iacute;n Abadi for helpful comments on early parts
  1929. of the design.
  1930. Chuck Blake,
  1931. Peter Bosch,
  1932. Frans Kaashoek,
  1933. Sape Mullender,
  1934. and
  1935. Lakshman Y. N.,
  1936. predominantly Dutchmen, gave helpful comments on the paper.
  1937. Russ Cox is supported by a fellowship from the Fannie and John Hertz Foundation.
  1938. <H4>References
  1939. </H4>
  1940. <br>&#32;<br>
  1941. [Bell93]
  1942. S.M. Bellovin and M. Merritt,
  1943. ``Augmented Encrypted Key Exchange,''
  1944. Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 244 - 250.
  1945. <br>&#32;<br>
  1946. [Boyk00]
  1947. Victor Boyko, Philip MacKenzie, and Sarvar Patel,
  1948. ``Provably Secure Password-Authenticated Key Exchange using Diffie-Hellman,''
  1949. Eurocrypt 2000, 156-171.
  1950. <br>&#32;<br>
  1951. [RFC2246]
  1952. T . Dierks and C. Allen,
  1953. ``The TLS Protocol, Version 1.0,''
  1954. RFC 2246.
  1955. <br>&#32;<br>
  1956. [Ford00]
  1957. Warwick Ford and Burton S. Kaliski, Jr.,
  1958. ``Server-Assisted Generation of a Strong Secret from a Password,''
  1959. IEEE Fifth International Workshop on Enterprise Security,
  1960. National Institute of Standards and Technology (NIST),
  1961. Gaithersburg MD, June 14 - 16, 2000.
  1962. <br>&#32;<br>
  1963. [Jabl]
  1964. David P. Jablon,
  1965. ``Strong Password-Only Authenticated Key Exchange,''
  1966. <TT>http://integritysciences.com/speke97.html</TT>.
  1967. <br>&#32;<br>
  1968. [Kami00]
  1969. Michael Kaminsky.
  1970. ``Flexible Key Management with SFS Agents,''
  1971. Master's Thesis, MIT, May 2000.
  1972. <br>&#32;<br>
  1973. [Mack]
  1974. Philip MacKenzie,
  1975. private communication.
  1976. <br>&#32;<br>
  1977. [Mazi99]
  1978. David Mazi&egrave;res, Michael Kaminsky, M. Frans Kaashoek and Emmett Witchel,
  1979. ``Separating key management from file system security,''
  1980. Symposium on Operating Systems Principles, 1999, pp. 124-139.
  1981. <br>&#32;<br>
  1982. [Micr]
  1983. Microsoft Passport,
  1984. <TT>http://www.passport.com/</TT>.
  1985. <br>&#32;<br>
  1986. [Perl99]
  1987. Radia Perlman and Charlie Kaufman,
  1988. ``Secure Password-Based Protocol for Downloading a Private Key,''
  1989. Proc. 1999 Network and Distributed System Security Symposium,
  1990. Internet Society, January 1999.
  1991. <br>&#32;<br>
  1992. [Pike95]
  1993. Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, and Phil Winterbottom,
  1994. ``Plan 9 from Bell Labs,''
  1995. Computing Systems, <B>8</B>, 3, Summer 1995, pp. 221-254.
  1996. <br>&#32;<br>
  1997. [Pike93]
  1998. Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom,
  1999. ``The Use of Name Spaces in Plan 9,''
  2000. Operating Systems Review, <B>27</B>, 2, April 1993, pp. 72-76
  2001. (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop,
  2002. Mont Saint-Michel, 1992, Paper n&#186; 34).
  2003. <br>&#32;<br>
  2004. [Resc01]
  2005. Eric Rescorla,
  2006. ``SSL and TLS: Designing and Building Secure Systems,''
  2007. Addison-Wesley, 2001. ISBN 0-201-61598-3, p. 387.
  2008. <br>&#32;<br>
  2009. [RFC2138]
  2010. C. Rigney, A. Rubens, W. Simpson, S. Willens,
  2011. ``Remote Authentication Dial In User Service (RADIUS),''
  2012. RFC2138, April 1997.
  2013. <br>&#32;<br>
  2014. [RiLa]
  2015. Ronald L. Rivest and Butler Lampson,
  2016. ``SDSI&#173;A Simple Distributed Security Infrastructure,''
  2017. <TT>http://theory.lcs.mit.edu/~rivest/sdsi10.ps</TT>.
  2018. <br>&#32;<br>
  2019. [Schn]
  2020. Bruce Schneier, Password Safe,
  2021. <TT>http://www.counterpane.com/passsafe.html</TT>.
  2022. <br>&#32;<br>
  2023. [Sama96]
  2024. Vipin Samar,
  2025. ``Unified Login with Pluggable Authentication Modules (PAM),''
  2026. Proceedings of the Third ACM Conference on Computer Communications and Security,
  2027. March 1996, New Delhi, India.
  2028. <br>&#32;<br>
  2029. [Stei88]
  2030. Jennifer G. Steiner, Clifford Neumann, and Jeffrey I. Schiller,
  2031. ``<I>Kerberos</I>: An Authentication Service for Open Network Systems,''
  2032. Proceedings of USENIX Winter Conference, Dallas, Texas, February 1988, pp. 191-202.
  2033. <br>&#32;<br>
  2034. [Wu98]
  2035. T. Wu,
  2036. ``The Secure Remote Password Protocol,''
  2037. Proceedings of
  2038. the 1998 Internet Society Network and Distributed System Security
  2039. Symposium, San Diego, CA, March 1998, pp. 97-111.
  2040. <br>&#32;<br>
  2041. [Ylon96]
  2042. Ylonen, T.,
  2043. ``SSH&#173;Secure Login Connections Over the Internet,''
  2044. 6th USENIX Security Symposium, pp. 37-42. San Jose, CA, July 1996.
  2045. <H4>Appendix: Summary of the PAK protocol
  2046. </H4>
  2047. <br>&#32;<br>
  2048. n(11Let 11&lt;I&gt;q&gt;&lt;/I&gt;2^16011n(99 and 11&lt;I&gt;p&gt;&lt;/I&gt;2^102411n(99 be primes
  2049. n(11such that 11&lt;I&gt;p=rq+&lt;/I&gt;1n(99 with 11&lt;I&gt;r&lt;/I&gt;n(99 not a multiple of 11&lt;I&gt;q&lt;/I&gt;n(99.
  2050. ^&lt;I&gt;*&lt;/I&gt;h'-0w'&lt;I&gt;*&lt;/I&gt;'u+0w'&lt;I&gt;*&lt;/I&gt;'u'11
  2051. n(11Take 11&lt;I&gt;h&lt;/I&gt;&lt;I&gt;&isin;&lt;/I&gt;&lt;I&gt;Z&lt;/I&gt;&lt;I&gt;p&lt;/I&gt;h'-0w'&lt;I&gt;p&lt;/I&gt;'u'n(99 such that 11&lt;I&gt;g&lt;/I&gt;==&lt;I&gt;h&lt;/I&gt;^&lt;I&gt;r&lt;/I&gt;11n(99 is not 1.
  2052. These parameters may be chosen by the NIST algorithm for DSA,
  2053. and are public, fixed values.
  2054. n(11The client 11&lt;I&gt;C&lt;/I&gt;n(99 knows a secret 11&#960;n(99
  2055. n(11and computes 11&lt;I&gt;H&lt;/I&gt;==(&lt;I&gt;H&lt;/I&gt;111(&lt;I&gt;C&lt;/I&gt;, &#960;)&lt;I&gt;&lt;/I&gt;)^&lt;I&gt;r&lt;/I&gt;11n(99 and 11&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111n(99,
  2056. ^&lt;I&gt;*&lt;/I&gt;h'-0w'&lt;I&gt;*&lt;/I&gt;'u+0w'&lt;I&gt;*&lt;/I&gt;'u'11
  2057. n(11where 11&lt;I&gt;H&lt;/I&gt;111n(99 is a hash function yielding a random element of 11&lt;I&gt;Z&lt;/I&gt;&lt;I&gt;p&lt;/I&gt;h'-0w'&lt;I&gt;p&lt;/I&gt;'u'n(99,
  2058. n(11and 11&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111n(99 may be computed by gcd.
  2059. n(11(All arithmetic is modulo 11&lt;I&gt;p&lt;/I&gt;n(99.)
  2060. n(11The client gives 11&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111n(99 to the server 11&lt;I&gt;S&lt;/I&gt;n(99 ahead of time by a private channel.
  2061. n(11To start a new connection, the client generates a random value 11&lt;I&gt;x&lt;/I&gt;n(99,
  2062. n(11computes 11&lt;I&gt;m&lt;/I&gt;==&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;x&lt;/I&gt;11&lt;I&gt;H&lt;/I&gt;n(99,
  2063. n(11then calls the server and sends 11&lt;I&gt;C&lt;/I&gt;n(99 and 11&lt;I&gt;m&lt;/I&gt;n(99.
  2064. n(11The server checks 11&lt;I&gt;m&lt;/I&gt;!=0 mod &lt;I&gt;p&lt;/I&gt;n(99,
  2065. n(11generates random 11&lt;I&gt;y&lt;/I&gt;n(99,
  2066. n(11computes 11&#956;==&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;y&lt;/I&gt;11n(99,
  2067. n(1111&#963;==(&lt;I&gt;m&lt;/I&gt;&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)^&lt;I&gt;y&lt;/I&gt;11n(99,
  2068. n(11and sends 11&lt;I&gt;S&lt;/I&gt;n(99, 11&#956;n(99, 11&lt;I&gt;k&lt;/I&gt;==&lt;I&gt;sha1&lt;/I&gt;("server",&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;m&lt;/I&gt;,&#956;,&#963;,&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)n(99.
  2069. n(11Next the client computes 11&#963;&lt;I&gt;=&lt;/I&gt;&#956;^&lt;I&gt;x&lt;/I&gt;11n(99,
  2070. n(11verifies 11&lt;I&gt;k&lt;/I&gt;n(99,
  2071. n(11and sends 11&lt;I&gt;k&#180;&lt;/I&gt;==&lt;I&gt;sha1&lt;/I&gt;("client",&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;m&lt;/I&gt;,&#956;,&#963;,&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)n(99.
  2072. n(11The server then verifies 11&lt;I&gt;k&#180;&lt;/I&gt;n(99 and both sides begin
  2073. n(11using session key 11&lt;I&gt;K&lt;/I&gt;==&lt;I&gt;sha1&lt;/I&gt;("session",&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;m&lt;/I&gt;,&#956;,&#963;,&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)n(99.
  2074. n(11In the published version of PAK, the server name 11&lt;I&gt;S&lt;/I&gt;n(99
  2075. is included in the initial
  2076. n(11hash 11&lt;I&gt;H&lt;/I&gt;n(99, but doing so is inconvenient in our application,
  2077. as the server may be known by various equivalent names.
  2078. <br>&#32;<br>
  2079. MacKenzie has shown
  2080. [Mack]
  2081. that the
  2082. equivalence proof [Boyk00]
  2083. can be adapted to cover our version.
  2084. <br>&#32;<br>
  2085. <A href=http://www.lucent.com/copyright.html>
  2086. Copyright</A> &#169; 2004 Lucent Technologies Inc. All rights reserved.
  2087. </body></html>