factotum.4 (20341B)
1 .TH FACTOTUM 4 2 .SH NAME 3 factotum \- authentication agent 4 .SH SYNOPSIS 5 .B factotum 6 [ 7 .B -DdkSun 8 ] [ 9 .B -a authaddr 10 ] [ 11 .B -s 12 .I srvname 13 ] 14 .\" [ 15 .\" .B -m 16 .\" .I mtpt 17 .\" ] 18 .PP 19 .B factotum 20 .B -g 21 .IB attribute = value 22 .B ... 23 .IB attribute ? 24 .B ... 25 .\" .PP 26 .\" .B auth/fgui 27 .SH DESCRIPTION 28 .I Factotum 29 is a user-level file system that 30 acts as the authentication agent for a user. 31 It does so by managing a set of 32 .IR keys . 33 A key is a collection of information used to authenticate a particular action. 34 Stored as a list of 35 .IB attribute = value 36 pairs, a key typically contains a user, an authentication domain, a protocol, and 37 some secret data. 38 .PP 39 .I Factotum 40 presents the following files: 41 .TF needkey 42 .TP 43 .B rpc 44 each open represents a new private channel to 45 .I factotum 46 .TP 47 .B proto 48 when read lists the protocols available 49 .TP 50 .B confirm 51 for confiming the use of key 52 .TP 53 .B needkey 54 allows external programs to control the addition of new keys 55 .TP 56 .B log 57 a log of actions 58 .TP 59 .B ctl 60 for maintaining keys; when read, it returns a list of keys. 61 For secret attributes, only the attribute name follow by a 62 .L ? 63 is returned. 64 .PD 65 .PP 66 In any authentication, the caller typically acts as a client 67 and the callee as a server. The server determines 68 the authentication domain, sometimes after a negotiation with 69 the client. Authentication always requires the client to 70 prove its identity to the server. Under some protocols, the 71 authentication is mutual. 72 Proof is accomplished using secret information kept by factotum 73 in conjunction with a cryptographic protocol. 74 .PP 75 .I Factotum 76 can act in the role of client for any process possessing the 77 same user id as it. For select protocols such as 78 .B p9sk1 79 it can also act as a client for other processes provided 80 its user id may speak for the other process' user id (see 81 Plan 9's 82 .IR authsrv (6)). 83 .I Factotum 84 can act in the role of server for any process. 85 .PP 86 .IR Factotum 's 87 structure is independent of 88 any particular authentication protocol. 89 .I Factotum 90 supports the following protocols: 91 .TF mschap 92 .TP 93 .B p9any 94 a metaprotocol used to negotiate which actual protocol to use. 95 .TP 96 .B p9sk1 97 a Plan 9 shared key protocol. 98 .TP 99 .B p9sk2 100 a variant of 101 .B p9sk1. 102 .TP 103 .B p9cr 104 a Plan 9 protocol that can use either 105 .B p9sk1 106 keys or SecureID tokens. 107 .TP 108 .B apop 109 the challenge/response protocol used by POP3 mail servers. 110 .TP 111 .B cram 112 the challenge/response protocol also used by POP3 mail servers. 113 .TP 114 .B chap 115 the challenge/response protocols used by PPP and PPTP. 116 .TP 117 .B dsa 118 DSA signatures, used by SSH 119 .TP 120 .B mschap 121 a proprietary Microsoft protocol also used by PPP and PPTP. 122 .TP 123 .B rsa 124 RSA encryption and signatures, used by SSH and TLS. 125 .TP 126 .B pass 127 passwords in the clear. 128 .TP 129 .B vnc 130 .MR vnc (1) 's 131 challenge/response. 132 .TP 133 .B wep 134 WEP passwords for wireless ethernet cards. 135 .PD 136 The ``Protocols'' section below describes these protocols in more detail. 137 .PP 138 The options to 139 .I factotum 140 are: 141 .TP 142 .B \-a 143 supplies the address of the authentication server to use. 144 Without this option, it will attempt to find an authentication server by 145 querying the connection server, the file 146 .BR <mtpt>/ndb , 147 and finally the network database in 148 .BR /lib/ndb . 149 .TP 150 .B \-m 151 specifies the mount point to use, by default 152 .BR /mnt . 153 .TP 154 .B \-s 155 specifies the service name to use. 156 Without this option, 157 .I factotum 158 does not create a service file in 159 .BR /srv . 160 .TP 161 .B \-D 162 turns on 9P tracing, written to standard error. 163 .TP 164 .B \-d 165 turns on debugging, written to standard error. 166 .TP 167 .B \-g 168 causes the agent to prompt for the key, write it 169 to the 170 .B ctl 171 file, and exit. 172 The agent will prompt for values for any of the 173 attributes ending with a question mark 174 .RB ( ? ) 175 and will append all the supplied 176 .I attribute = value 177 pairs. See the section on key templates below. 178 .TP 179 .B \-n 180 don't look for a secstore. 181 .TP 182 .B \-S 183 indicates that the agent is running on a 184 cpu server. On starting, it will attempt to get a 185 .B 9psk1 186 key from NVRAM using 187 .B readnvram 188 (see 189 .MR authsrv (3) ), 190 prompting for anything it needs. 191 It will never subsequently prompt for a 192 key that it doesn't have. 193 This option is typically used by 194 the kernel at boot time. 195 .TP 196 .B \-k 197 causes the NVRAM to be written. 198 It is only valid with the 199 .B \-S 200 option. 201 This option is typically used by 202 the kernel at boot time. 203 .TP 204 .B \-u 205 causes the agent to prompt for user 206 id and writes it to 207 .BR /dev/hostowner . 208 It is mutually exclusive with 209 .B \-k 210 and 211 .BR \-S . 212 This option is typically used by 213 the kernel at boot time. 214 .PD 215 .\" .PP 216 .\" .I Fgui 217 .\" is a graphic user interface for confirming key usage and 218 .\" entering new keys. It hides the window in which it starts 219 .\" and waits reading requests from 220 .\" .B confirm 221 .\" and 222 .\" .BR needkey . 223 .\" For each requests, it unhides itself and waits for 224 .\" user input. 225 .\" See the sections on key confirmation and key prompting below. 226 .SS "Key Tuples 227 .PP 228 A 229 .I "key tuple 230 is a space delimited list of 231 .IB attribute = value 232 pairs. An attribute whose name begins with an exclamation point 233 .RB ( ! ) 234 does not appear when reading the 235 .B ctl 236 file. 237 Here are some examples: 238 .EX 239 proto=p9sk1 dom=avayalabs.com user=presotto !password=lucent 240 proto=apop server=mit.edu user=rsc !password=nerdsRus 241 proto=pass user=tb service=ssh !password=does.it.matter 242 .EE 243 The ``Protocols'' section below describes the attributes 244 specific to each supported protocol. 245 .PP 246 All keys can have additional attibutes that act either as comments 247 or as selectors to distinguish them in the 248 .MR auth (3) 249 library calls. 250 .PP 251 The factotum owner can use any key stored by factotum. 252 Any key may have one or more 253 .B owner 254 attributes listing the users who can use the key 255 as though they were the owner. 256 For example, the TLS and SSH host keys on a server 257 often have an attribute 258 .B owner=* 259 to allow any user (and in particular, 260 .L none ) 261 to run the TLS or SSH server-side protocol. 262 .PP 263 Any key may have a 264 .B role 265 attribute for restricting how it can be used. 266 If this attribute is missing, the key can be used in any role. 267 Common values are: 268 .TP 269 .B client 270 for authenticating outbound calls 271 .TP 272 .B server 273 for authenticating inbound calls 274 .TP 275 .B speaksfor 276 for authenticating processes whose 277 user id does not match 278 .IR factotum 's. 279 .TP 280 .B encrypt 281 for encrypting data 282 .TP 283 .B decrypt 284 for decrypting data 285 .TP 286 .B sign 287 for cryptographically signing data 288 .TP 289 .B verify 290 for verifying cryptographic signatures 291 .PD 292 .PP 293 Whenever 294 .I factotum 295 runs as a server, it must have a 296 .B p9sk1 297 key in order to communicate with the authentication 298 server for validating passwords and challenge/responses of 299 other users. 300 .SS "Key Templates 301 Key templates are used by routines that interface to 302 .I factotum 303 such as 304 .B auth_proxy 305 and 306 .B auth_challenge 307 (see 308 .MR auth (3) ) 309 to specify which key and protocol to use for an authentication. 310 Like a key tuple, a key template is also a list of 311 .IB attribute = value 312 pairs. 313 It must specify at least the protocol and enough 314 other attributes to uniquely identify a key, or set of keys, to use. 315 The keys chosen are those that match all the attributes specified 316 in the template. The possible attribute/value formats are: 317 .TP 1i 318 .IB attr = val 319 The attribute 320 .I attr 321 must exist in the key and its value must exactly 322 match 323 .I val 324 .TP 1i 325 .IB attr ? 326 The attribute 327 .I attr 328 must exist in the key but its value doesn't matter. 329 .TP 1i 330 .I attr 331 The attribute 332 .I attr 333 must exist in the key with a null value 334 .PD 335 .PP 336 Key templates are also used by factotum to request a key either via 337 an RPC error or via the 338 .B needkey 339 interface. 340 The possible attribute/value formats are: 341 .TP 1i 342 .IB attr = val 343 This pair must remain unchanged 344 .TP 1i 345 .IB attr ? 346 This attribute needs a value 347 .TP 1i 348 .I attr 349 The pair must remain unchanged 350 .PD 351 .SS "Control and Key Management 352 .PP 353 A number of messages can be written to the control file. 354 The mesages are: 355 .TP 356 .B "key \fIattribute-value-list\fP 357 add a new key. This will replace any old key whose 358 public, i.e. non ! attributes, match. 359 .TP 360 .B "delkey \fIattribute-value-list\fP 361 delete a key whose attributes match those given. 362 .TP 363 .B debug 364 toggle debugging on and off, i.e., the debugging also 365 turned on by the 366 .B \-d 367 option. 368 .PP 369 By default when factotum starts it looks for a 370 .MR secstore (1) 371 account on $auth for the user and, if one exists, 372 prompts for a secstore password in order to fetch 373 the file 374 .IR factotum , 375 which should contain control file commands. 376 An example would be 377 .EX 378 key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229 379 key proto=rsa service=ssh size=1024 ek=3B !dk=... 380 .EE 381 where the first line sets a password for 382 challenge/response authentication, strong against dictionary 383 attack by being a long random string, and the second line 384 sets a public/private keypair for ssh authentication, 385 generated by 386 .B ssh_genkey 387 (see 388 .MR ssh (1) ). 389 .PD 390 .SS "Confirming key use 391 .PP 392 The 393 .B confirm 394 file provides a connection from 395 .I factotum 396 to a confirmation server, normally the program 397 .IR auth/fgui . 398 Whenever a key with the 399 .B confirm 400 attribute is used, 401 .I factotum 402 requires confirmation of its use. If no process has 403 .B confirm 404 opened, use of the key will be denied. 405 However, if the file is opened a request can be read from it 406 with the following format: 407 .PP 408 .B confirm 409 .BI tag= tagno 410 .I "<key template> 411 .PP 412 The reply, written back to 413 .BR confirm , 414 consists of string: 415 .PP 416 .BI tag= tagno 417 .BI answer= xxx 418 .PP 419 If 420 .I xxx 421 is the string 422 .B yes 423 then the use is confirmed and the authentication will proceed. 424 Otherwise, it fails. 425 .PP 426 .B Confirm 427 is exclusive open and can only be opened by a process with 428 the same user id as 429 .IR factotum . 430 .SS "Prompting for keys 431 .PP 432 The 433 .B needkey 434 file provides a connection from 435 .I factotum 436 to a key server, normally the program 437 .IR auth/fgui . 438 Whenever 439 .I factotum 440 needs a new key, it first checks to see if 441 .B needkey 442 is opened. If it isn't, it returns a error to its client. 443 If the file is opened a request can be read from it 444 with the following format: 445 .PP 446 .B needkey 447 .BI tag= tagno 448 .I "<key template> 449 .PP 450 It is up to the reader to then query the user for any missing fields, 451 write the key tuple into the 452 .B ctl 453 file, and then reply by writing into the 454 .B needkey 455 file the string: 456 .PP 457 .BI tag= tagno 458 .PP 459 .B Needkey 460 is exclusive open and can only be opened by a process with 461 the same user id as 462 .IR factotum . 463 .SS "The RPC Protocol 464 Authentication is performed by 465 .IP 1) 466 opening 467 .BR rpc 468 .IP 2) 469 setting up the protocol and key to be used (see the 470 .B start 471 RPC below), 472 .IP 3) 473 shuttling messages back and forth between 474 .IR factotum 475 and the other party (see the 476 .B read 477 and 478 .B write 479 RPC's) until done 480 .IP 4) 481 if successful, reading back an 482 .I AuthInfo 483 structure (see 484 .MR authsrv (3) ). 485 .PP 486 The RPC protocol is normally embodied by one of the 487 routines in 488 .MR auth (3) . 489 We describe it here should anyone want to extend 490 the library. 491 .PP 492 An RPC consists of writing a request message to 493 .B rpc 494 followed by reading a reply message back. 495 RPC's are strictly ordered; requests and replies of 496 different RPC's cannot be interleaved. 497 Messages consist of a verb, a single space, and data. 498 The data format depends on the verb. The request verbs are: 499 .TP 500 .B "start \fIattribute-value-list\fP 501 start a new authentication. 502 .I Attribute-value-pair-list 503 must include a 504 .B proto 505 attribute, a 506 .B role 507 attribute with value 508 .B client 509 or 510 .BR server , 511 and enough other attibutes to uniquely identify a key to use. 512 A 513 .B start 514 RPC is required before any others. The possible replies are: 515 .RS 516 .TP 517 .B ok 518 start succeeded. 519 .TP 520 .B "error \fIstring\fP 521 where 522 .I string 523 is the reason. 524 .RE 525 .PD 526 .TP 527 .B read 528 get data from 529 .I factotum 530 to send to the other party. The possible replies are: 531 .RS 532 .TP 533 .B ok 534 read succeeded, this is zero length message. 535 .TP 536 .B "ok \fIdata\fP 537 read succeeded, the data follows the space and is 538 unformatted. 539 .TP 540 .B "done 541 authentication has succeeded, no further RPC's are 542 necessary 543 .TP 544 .B "done haveai 545 authentication has succeeded, an 546 .B AuthInfo 547 structure (see 548 .MR auth (3) ) 549 can be retrieved with an 550 .B authinfo 551 RPC 552 .TP 553 .B "phase \fIstring\fP 554 its not your turn to read, get some data from 555 the other party and return it with a write RPC. 556 .TP 557 .B "error \fIstring\fP 558 authentication failed, 559 .I string 560 is the reason. 561 .TP 562 .B "protocol not started 563 a 564 .B start 565 RPC needs to precede reads and writes 566 .TP 567 .B "needkey \fIattribute-value-list\fP 568 a key matching the argument is needed. This argument 569 may be passed as an argument to 570 .I factotum 571 .B -g 572 in order to prompt for a key. After that, the 573 authentication may proceed, i.e., the read restarted. 574 .PD 575 .RE 576 .TP 577 .B "write \fIdata\fP 578 send data from the other party to 579 .IR factotum . 580 The possible replies are: 581 .RS 582 .TP 583 .B "ok 584 the write succeeded 585 .TP 586 .B "needkey \fIattribute-value-list\fP 587 see above 588 .TP 589 .B "toosmall \fIn\fP 590 the write is too short, get more data from the 591 other party and retry the write. 592 .I n 593 specifies the maximun total number of bytes. 594 .TP 595 .B "phase \fIstring\fP 596 its not your turn to write, get some data from 597 .I factotum 598 first. 599 .TP 600 .B "done 601 see above 602 .TP 603 .B "done haveai 604 see above 605 .RE 606 .TP 607 .B readhex\fR, \fPwritehex 608 like 609 .B read 610 and 611 .BR write , 612 except that an 613 .B ok 614 response to 615 .B readhex 616 returns the data encoded as 617 a long hexadecimal string, 618 and the argument to 619 .B writehex 620 is expected to be a long hexadecimal string. 621 These are useful for manually debugging of binary protocols. 622 .TP 623 .B authinfo 624 retrieve the AuthInfo structure. 625 The possible replies are: 626 .RS 627 .TP 628 .B "ok \fIdata\fP 629 .I data 630 is a marshaled form of the AuthInfo structure. 631 .TP 632 .B "error \fIstring\fP 633 where 634 .I string 635 is the reason for the error. 636 .PD 637 .RE 638 .TP 639 .B attr 640 retrieve the attributes used in the 641 .B start 642 RPC. 643 The possible replies are: 644 .RS 645 .TP 646 .B "ok \fIattribute-value-list\fP 647 .TP 648 .B "error \fIstring\fP 649 where 650 .I string 651 is the reason for the error. 652 .PD 653 .RE 654 .SS Protocols 655 Factotum supports many authentication types, each 656 with its own roles and required key attributes. 657 .PP 658 .IR P9any , 659 .IR p9sk1 , 660 .IR p9sk2 , 661 and 662 .I p9cr 663 are used to authenticate to Plan 9 systems; 664 valid 665 .BR role s 666 are 667 .B client 668 and 669 .BR server . 670 All require 671 .B proto=p9sk1 672 keys with 673 .BR user , 674 .B dom 675 (authentication domain), 676 and 677 .B !password 678 attributes. 679 .PP 680 .I P9sk1 681 and 682 .I p9sk2 683 are the Plan 9 shared-key authentication protocols. 684 .I P9sk2 685 is a deprecated form of 686 .I p9sk1 687 that neglects to authenticate the server. 688 .PP 689 .I P9any 690 is a meta-protocol that negotiates a protocol 691 .RB ( p9sk1 692 or 693 .BR p9sk2 ) 694 and an authentication domain and then invokes the 695 given protocol with a 696 .B dom= 697 attribute. 698 .PP 699 .IR P9any , 700 .IR p9sk1 , 701 and 702 .I p9sk2 703 are intended to be proxied via 704 .I auth_proxy 705 (see 706 .MR auth (3) ). 707 .\" The protocols follow 708 .\" .IR p9any (7) 709 .\" and 710 .\" .IR p9sk1 (7). 711 .\" XXX - write about how server keys are selected and used 712 .\" XXX - write about protocol itself 713 .\" XXX - write about server ai 714 .PP 715 .I P9cr 716 is a textual challenge-response protocol; 717 roles are 718 .B client 719 and 720 .BR server . 721 It uses 722 .I p9sk1 723 keys as described above. 724 The protocol with 725 .I factotum 726 is textual: 727 client writes a user name, 728 server responds with a challenge, 729 client writes a response, 730 server responds with 731 .B ok 732 or 733 .BR bad . 734 Typically this information is wrapped in other protocols 735 before being sent over the network. 736 .PP 737 .I Vnc 738 is the challenge-response protocol used by 739 .MR vnc (1) ; 740 valid roles are 741 .B client 742 and 743 .BR server . 744 The client protocol requires a 745 .B proto=vnc 746 key with attribute 747 .BR !password . 748 Conventionally, client keys also have 749 .B user 750 and 751 .B server 752 attributes. 753 The server protocol requires a 754 .I p9sk1 755 key as described above. 756 The protocol with 757 .I factotum 758 is the same as 759 .IR p9cr , 760 except that the challenge and response are not textual. 761 .PP 762 .I Apop 763 and 764 .I cram 765 are challenge-response protocols typically 766 used to authenticate 767 to mail servers. 768 The client protocols require 769 .B proto=apop 770 or 771 .B proto=cram 772 keys with 773 .B user 774 and 775 .B !password 776 attributes. 777 Conventionally, client keys also have 778 .B server 779 attributes. 780 The server protocol requires a 781 .I p9sk1 782 key as described above. 783 The protocol with 784 .I factotum 785 is textual: 786 server writes a challenge of the form 787 .IB random @ domain \fR, 788 client responds with user name 789 and then a hexadecimal response 790 (two separate writes), 791 and then the server responds with 792 .B ok 793 or 794 .BR bad . 795 .PP 796 .I Chap 797 and 798 .I mschap 799 are challenge-response protocols used in PPP sessions; 800 valid roles are 801 .B client 802 and 803 .BR server . 804 The client protocols require 805 .B proto=chap 806 or 807 .B proto=mschap 808 keys with 809 .B user 810 and 811 .B !password 812 attributes. 813 Conventionally, client keys also have 814 .B server 815 attributes. 816 The server protocol requires a 817 .I p9sk1 818 key as described above. 819 The protocol with factotum is: 820 server writes an 8-byte binary challenge, 821 client responds with user name 822 and then a 823 .B Chapreply 824 or 825 .B MSchapreply 826 structure (defined in 827 .B <auth.h> ). 828 .PP 829 .I Pass 830 is a client-only protocol that hands out passwords 831 from 832 .B proto=pass 833 keys with 834 .B user 835 and 836 .B !password 837 attributes. 838 The protocol is a single read that returns 839 a string: a space-separated quoted user name and password 840 that can be parsed with 841 .I tokenize 842 (see 843 .MR getfields (3) ). 844 Conventionally, client keys have distinguishing attributes 845 like 846 .B service 847 and 848 .B server 849 that can be specified in the 850 .B start 851 message to select a key. 852 .PP 853 .I Wep 854 is a client-only pseudo-protocol that initializes the encryption 855 key on a wireless ethernet device. 856 It uses 857 .B proto=wep 858 keys with 859 .BR !key1 , 860 .BR !key2 , 861 or 862 .B !key3 863 attributes. 864 The protocol with 865 .I factotum 866 is: 867 the client writes a device name 868 that must begin with 869 .LR #l . 870 In response, 871 .I factotum 872 opens the device's control file, sets the wireless secret using the key, 873 and turns on encryption. 874 If the key has an 875 .B essid 876 attribute, 877 .I factotum 878 uses it to set the wireless station ID. 879 .PP 880 .I Rsa 881 is an implementation of the RSA protocol. 882 Valid roles are 883 .BR decrypt , 884 .BR encrypt , 885 .BR sign , 886 and 887 .BR verify . 888 .I Rsa 889 uses 890 .B proto=rsa 891 keys with 892 .B ek 893 and 894 .B n 895 attributes, large integers specifying the public half 896 of the key. 897 If a key is to be used for decryption or signing, 898 then it must also have attributes 899 .BR !p , 900 .BR !q , 901 .BR !kp , 902 .BR !kq , 903 .BR !c2 , 904 and 905 .BR !dk 906 specifying the private half of the key; 907 see 908 .MR rsa (3) . 909 Conventionally, 910 .I rsa 911 keys also have 912 .B service 913 attributes specifying the context in which the key is used: 914 .B ssh 915 (SSH version 1), 916 .B ssh-rsa 917 (SSH version 2), 918 or 919 .B tls 920 (SSL and TLS). 921 If an SSH key has a 922 .B comment 923 attribute, that comment is presented to remote SSH servers 924 during key negotiation. 925 The protocol for 926 encryption (decryption) is: 927 write the message, then read back the encrypted (decrypted) form. 928 The protocol for signing is: 929 write a hash of the actual message, 930 then read back the signature. 931 The protocol for verifying a signature is: 932 write the message hash, 933 write the purported signature, 934 then read back 935 .B ok 936 or 937 .B bad 938 telling whether the signature could be verified. 939 The hash defaults to SHA1 but can be specified by a 940 .B hash 941 attribute on the key. 942 Valid hash functions are 943 .B md5 944 and 945 .BR sha1 . 946 The hash function must be known to 947 .I factotum 948 because the signature encodes the type of hash used. 949 The 950 .B encrypt 951 and 952 .B verify 953 operations are included as a convenience; 954 .I factotum 955 is not using any private information to perform them. 956 .PP 957 .I Dsa 958 is an implementation of the NIST digital signature algorithm. 959 Valid roles are 960 .B sign 961 and 962 .BR verify . 963 It uses 964 .B proto=dsa 965 keys with 966 .BR p , 967 .BR q , 968 .BR alpha , 969 and 970 .B key 971 attributes. 972 If the key is to be used for signing, it must also have a 973 .B !secret 974 attribute; see 975 .MR dsa (3) . 976 Conventionally, 977 .I dsa 978 keys 979 also have 980 .B service 981 attributes specifying the context in which the key is used: 982 .B ssh-dss 983 (SSH version 2) 984 is the only one. 985 If an SSH key has a 986 .B comment 987 attribute, that comment is presented to SSH servers during 988 key negotiation. 989 The protocol for signing and verifying 990 is the same as the RSA protocol. 991 Unlike 992 .IR rsa , 993 the 994 .I dsa 995 protocol ignores the 996 .B hash 997 attribute; it always uses SHA1. 998 .PP 999 .I Httpdigest 1000 is a client-only MD5-based challenge-response protocol used in HTTP; see RFC 2617. 1001 It uses 1002 .B proto=httpdigest 1003 keys with 1004 .BR user , 1005 .BR realm , 1006 and 1007 .BR !password 1008 attributes. 1009 The protocol with factotum is textual: 1010 write the challenge, read the response. 1011 The challenge is a string with three space-separated fields 1012 .IR nonce , 1013 .IR method , 1014 and 1015 .IR uri , 1016 parseable with 1017 .IR tokenize . 1018 The response is a hexadecimal string of length 32. 1019 .SH SOURCE 1020 .B \*9/src/cmd/auth/factotum 1021 .SH SEE ALSO 1022 .MR ssh-agent (1)