tfactotum.4 - plan9port - [fork] Plan 9 from user space
HTML git clone git://src.adamsgaard.dk/plan9port
DIR Log
DIR Files
DIR Refs
DIR README
DIR LICENSE
---
tfactotum.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)