man.aiju.de 9front man pages

FACTOTUM(4)FACTOTUM(4)

NAME

factotum, fgui, userpasswd – authentication agent

SYNOPSIS

auth/factotum [ -DdknpuS ] [ -a asaddr ] [ -s srvname ] [ -m mtpt ]

auth/factotum -g attribute=value ... attribute? ...

auth/fgui

auth/userpasswd fmt

DESCRIPTION

Factotum is a user-level file system that acts as the authentication agent for a user. It does so by managing a set of keys. A key is a collection of information used to authenticate a particular action. Stored as a list of attribute=value pairs, a key typically contains a user, an authentication domain, a protocol, and some secret data.

Factotum presents a two level directory. The first level contains a single directory factotum, which in turn contains:

each open represents a new private channel to factotum  

when read lists the protocols available  

for confiming the use of key  

allows external programs to control the addition of new keys  

a log of actions  

for maintaining keys; when read, it returns a list of keys. For secret attributes, only the attribute name follow by a ? is returned.  

In any authentication, the caller typically acts as a client and the callee as a server. The server determines the authentication domain, sometimes after a negotiation with the client. Authentication always requires the client to prove its identity to the server. Under some protocols, the authentication is mutual. Proof is accomplished using secret information kept by factotum in conjunction with a cryptographic protocol.

Factotum can act in the role of client for any process possessing the same user id as it. For select protocols such as p9sk1 and dp9ik it can also act as a client for other processes provided its user id may speak for the other process’ user id (see authsrv(6)). Factotum can act in the role of server for any process.

Factotum’s structure is independent of any particular authentication protocol. Factotum supports the following protocols:

a metaprotocol used to negotiate which actual protocol to use.  

legacy Plan 9 shared key protocol described in authsrv(6)’s “Ticket Service” and “P9sk1” sections.  

extended version of p9sk1 that adds password bruteforce resistance and forward secrecy (see authsrv(6)’s “Password authenticated key exchange” and “Dp9ik” sections).  

legacy Plan 9 protocol that can use either p9sk1 keys or SecureID tokens.  

the challenge/response protocol used by POP3 mail servers.  

the challenge/response protocol also used by POP3 mail servers.  

the challenge/response protocols used by PPP and PPTP.  

a proprietary Microsoft challenge/response protocol also used by PPP, PPTP and CIFS.  

version two of Microsofts challenge/response protocol used by WPA.  

Microsofts NTLMv2 challenge/response protocol used by CIFS.  

RSA public key decryption, used by SSH and TLS.  

passwords in the clear.  

vnc(1)’s challenge/response.  

WPA passwords for wireless ethernet cards.  

The options are:

supplies the address of the authentication server to use. Without this option, it will attempt to find an authentication server by querying the connection server, the file <mtpt>/ndb, and finally the network database in /lib/ndb.  

specifies the mount point to use, by default /mnt.  

specifies the service name to use. Without this option, factotum does not create a service file in /srv.  

turns on 9P tracing, written to standard error.  

turns on debugging, written to standard error.  

causes the agent to prompt for the key, write it to the ctl file, and exit. The agent will prompt for values for any of the attributes ending with a question mark (?) and will append all the supplied attribute = value pairs. See the section on key templates below.  

don’t look for a secstore.  

indicates that the agent is running on a CPU server. On starting, it will attempt to get p9sk1 and dp9ik keys from NVRAM using readnvram (see authsrv(2)), prompting for anything it needs. It will never subsequently prompt for a key that it doesn’t have. This option is typically used by the kernel at boot time.  

causes the NVRAM to be written. It is only valid with the –S option. This option is typically used by the kernel at boot time.  

causes the agent to prompt for user id and writes it to /dev/hostowner. It is mutually exclusive with –k and –S. This option is typically used by the kernel at boot time.  

causes the agent not to mark itself ‘private’ via proc(3), so that it can be debugged. It is implied by –d.  

Fgui is a graphic user interface for confirming key usage and entering new keys. It hides the window in which it starts and waits reading requests from confirm and needkey. For each requests, it unhides itself and waits for user input. See the sections on key confirmation and key prompting below.

Userpasswd queries and prints a cleartext user/password pair from factotum for the proto=pass key tuple specified in fmt. This can be used by shell scripts to do cleartext password authentication.

Key Tuples

A key tuple is a space delimited list of attribute=value pairs. An attribute whose name begins with an exclamation point (!) does not appear when reading the ctl file. The required attributes depend on the authentication protocol.

Dp9ik, p9sk1 and p9cr all require a key with proto=dp9ik or proto=p9sk1, a dom attribute identifying the authentication domain, a user name valid in that domain, and either a !password or !hex attribute specifying the password or hexadecimal secret to be used. Here is an example:

    proto=dp9ik dom=9front user=glenda !password=secret

Apop, cram, chap, and mschap, require a key with a proto attribute whose value matches the protocol, in addition to server, user, and !password attributes; e.g.

    proto=apop server=mit.edu user=rsc !password=nerdsRus

Vnc is similar but does not require a user attribute.

Pass requires a key with proto=pass in addition to user and !password attributes; e.g.

    proto=pass user=tb !password=does.it.matter

Rsa requires a key with proto=rsa in addition to all the hex attributes defining an RSA key: ek, n, !p, !q, !kp, !kq, !c2, and !dk. By convention, programs using the RSA protocol also require a service attribute set to ssh or tls.

All keys can have additional attributes that act either as comments or as selectors to distinguish them in the auth(2) library calls.

The factotum owner can use any key stored by factotum. Any key may have one or more owner attributes listing the users who can use the key as though they were the owner. For example, the TLS and SSH host keys on a server often have an attribute owner=* to allow any user (and in particular, none) to run the TLS or SSH server-side protocol.

Any key may have a role attribute for restricting how it can be used. If this attribute is missing, the key can be used in any role. The possible values are:

for authenticating outbound calls  

for authenticating inbound calls  

for authenticating processes whose user id does not match factotum’s.  

If a key has a disabled attribute (with any value), the key is not used during any protocols. Factotum automatically marks keys with disabled=by.factotum when they fail during certain authentication protocols (in particular, the Plan 9 ones).

Whenever factotum runs as a server, it must have dp9ik or p9sk1 keys in order to communicate with the authentication server for validating passwords and challenge/responses of other users.

Key Templates

Key templates are used by routines that interface to factotum such as auth_proxy and auth_challenge (see auth(2)) to specify which key and protocol to use for an authentication. Like a key tuple, a key template is also a list of attribute=value pairs. It must specify at least the protocol and enough other attributes to uniquely identify a key, or set of keys, to use. The keys chosen are those that match all the attributes specified in the template. The possible attribute/value formats are:

The attribute attr must exist in the key and its value must exactly match val  

The attribute attr must exist in the key but its value doesn’t matter.  

The attribute attr must exist in the key with a null value  

Key templates are also used by factotum to request a key either via an RPC error or via the needkey interface. The possible attribute/value formats are:

This pair must remain unchanged  

This attribute needs a value  

The pair must remain unchanged  

Control and Key Management

A number of messages can be written to the control file. The messages are:

add a new key. This will replace any old key whose public, i.e. non ! attributes, match.  

delete a key whose attributes match those given.  

toggle debugging on and off, i.e., the debugging also turned on by the –d option.  

By default when factotum starts it looks for a secstore(1) account on $auth for the user and, if one exists, prompts for a secstore password in order to fetch the file factotum, which should contain control file commands. An example would be

  key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229
  key proto=rsa service=ssh size=1024 ek=3B !dk=...

where the first line sets a password for challenge/response authentication, strong against dictionary attack by being a long random string, and the second line sets a public/private keypair for ssh authentication.

Confirming key use

The confirm file provides a connection from factotum to a confirmation server, normally the program auth/fgui. Whenever a key with the confirm attribute is used, factotum requires confirmation of its use. If no process has confirm opened, use of the key will be denied. However, if the file is opened a request can be read from it with the following format:

confirm tag=tagno <key template>

The reply, written back to confirm, consists of string:

tag=tagno answer=xxx

If xxx is the string yes then the use is confirmed and the authentication will proceed. Otherwise, it fails.

Confirm is exclusive open and can only be opened by a process with the same user id as factotum.

Prompting for keys

The needkey file provides a connection from factotum to a key server, normally the program auth/fgui. Whenever factotum needs a new key, it first checks to see if needkey is opened. If it isn’t, it returns a error to its client. If the file is opened a request can be read from it with the following format:

needkey tag=tagno <key template>

It is up to the reader to then query the user for any missing fields, write the key tuple into the ctl file, and then reply by writing into the needkey file the string:

tag=tagno

Needkey is exclusive open and can only be opened by a process with the same user id as factotum.

The RPC Protocol

Authentication is performed by

opening rpc  

setting up the protocol and key to be used (see the start RPC below),  

shuttling messages back and forth between factotum and the other party (see the read and write RPC’s) until done  

if successful, reading back an AuthInfo structure (see authsrv(2)).  

The RPC protocol is normally embodied by one of the routines in auth(2). We describe it here should anyone want to extend the library.

An RPC consists of writing a request message to rpc followed by reading a reply message back. RPC’s are strictly ordered; requests and replies of different RPC’s cannot be interleaved. Messages consist of a verb, a single space, and data. The data format depends on the verb. The request verbs are:

start a new authentication. Attribute-value-pair-list must include a proto attribute, a role attribute with value client or server, and enough other attributes to uniquely identify a key to use. A start RPC is required before any others. The possible replies are:  

start succeeded.  

where string is the reason.  

get data from factotum to send to the other party. The possible replies are:  

read succeeded, this is zero length message.  

read succeeded, the data follows the space and is unformatted.  

authentication has succeeded, no further RPC’s are necessary  

authentication has succeeded, an AuthInfo structure (see auth(2)) can be retrieved with an authinfo RPC  

its not your turn to read, get some data from the other party and return it with a write RPC.  

authentication failed, string is the reason.  

a start RPC needs to precede reads and writes  

a key matching the argument is needed. This argument may be passed as an argument to factotum -g in order to prompt for a key. After that, the authentication may proceed, i.e., the read restarted.  

send data from the other party to factotum. The possible replies are:  

the write succeeded  

see above  

the write is too short, get more data from the other party and retry the write. n specifies the maximun total number of bytes.  

its not your turn to write, get some data from factotum first.  

see above  

see above  

retrieve the AuthInfo structure. The possible replies are:  

data is a marshaled form of the AuthInfo structure.  

where string is the reason for the error.  

retrieve the attributes used in the start RPC. The possible replies are:  

where string is the reason for the error.  

SOURCE

/sys/src/cmd/auth/factotum

SEE ALSO

authsrv(6)