factotum(4) - Plan 9 from User Space

| FACTOTUM(4) | FACTOTUM(4)
| NAME
| factotum – authentication agent
SYNOPSIS
| `factotum` [ `−DdkSun` ] [ `−a authaddr` ] [ `−s` srvname ]
`factotum −g` attribute`=`value `...` attribute`? ...`
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 the following files: `rpc` each open represents a new private channel to factotum `proto` when read lists the protocols available `confirm` for confiming the use of key `needkey` allows external programs to control the addition of new keys `log` a log of actions `ctl` 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` it can also act as a client for other processes provided its user id may speak for the other process’ user id (see Plan 9’s 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: `p9any` a metaprotocol used to negotiate which actual protocol to use. `p9sk1` a Plan 9 shared key protocol. `p9sk2` a variant of `p9sk1. p9cr` a Plan 9 protocol that can use either `p9sk1` keys or SecureID tokens. `apop` the challenge/response protocol used by POP3 mail servers. `cram` the challenge/response protocol also used by POP3 mail servers. `chap` the challenge/response protocols used by PPP and PPTP. `dsa` DSA signatures, used by SSH `mschap` a proprietary Microsoft protocol also used by PPP and PPTP. `rsa` RSA encryption and signatures, used by SSH and TLS. `pass` passwords in the clear. `vnc`vnc(1)’s challenge/response. `wep` WEP passwords for wireless ethernet cards. The “Protocols” section below describes these protocols in more detail.
The options to factotum are: `–a` 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`. `–m` specifies the mount point to use, by default `/mnt`. `–s` specifies the service name to use. Without this option, factotum does not create a service file in `/srv`. `–D` turns on 9P tracing, written to standard error. `–d` turns on debugging, written to standard error. `–g` 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. `–n` don’t look for a secstore. `–S` indicates that the agent is running on a cpu server. On starting, it will attempt to get a `9psk1` key from NVRAM using `readnvram` (see authsrv(3)), 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. `–k` 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. `–u` 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. 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. Here are some examples:
| `proto=p9sk1 dom=avayalabs.com user=presotto !password=lucent proto=apop server=mit.edu user=rsc !password=nerdsRus proto=pass user=tb service=ssh !password=does.it.matter`
The “Protocols” section below describes the attributes specific to each supported protocol.
All keys can have additional attibutes that act either as comments or as selectors to distinguish them in the auth(3) 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. Common values are: `client`
| for authenticating outbound calls
`server`
| for authenticating inbound calls
`speaksfor`
| for authenticating processes whose user id does not match factotum’s.
`encrypt`
| for encrypting data
`decrypt`
| for decrypting data
`sign` for cryptographically signing data `verify`
| for verifying cryptographic signatures
Whenever factotum runs as a server, it must have a `p9sk1` key 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(3)) 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: attr`=`val The attribute attr must exist in the key and its value must exactly match val attr`?` The attribute attr must exist in the key but its value doesn’t matter. attr 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: attr`=`val This pair must remain unchanged attr`?` This attribute needs a value attr The pair must remain unchanged Control and Key Management
A number of messages can be written to the control file. The mesages are: `key` attribute-value-list
| add a new key. This will replace any old key whose public, i.e. non ! attributes, match.
`delkey` attribute-value-list
| delete a key whose attributes match those given.
`debug`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, generated by `ssh_genkey` (see ssh(1)). 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 1) opening `rpc` 2) setting up the protocol and key to be used (see the `start` RPC below), 3) shuttling messages back and forth between factotum and the other party (see the `read` and `write` RPC’s) until done 4) if successful, reading back an AuthInfo structure (see authsrv(3)).
The RPC protocol is normally embodied by one of the routines in auth(3). 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` attribute-value-list
| start a new authentication. Attribute-value-pair-list must include a `proto` attribute, a `role` attribute with value `client` or `server`, and enough other attibutes to uniquely identify a key to use. A `start` RPC is required before any others. The possible replies are: `ok` start succeeded. `error` string
| where string is the reason.
`read` get data from factotum to send to the other party. The possible replies are:
| `ok` read succeeded, this is zero length message. `ok` data
| read succeeded, the data follows the space and is unformatted.
`done` authentication has succeeded, no further RPC’s are necessary `done haveai`
| authentication has succeeded, an `AuthInfo` structure (see auth(3)) can be retrieved with an `authinfo` RPC
`phase` string
| its not your turn to read, get some data from the other party and return it with a write RPC.
`error` string
| authentication failed, string is the reason.
`protocol not started`
| a `start` RPC needs to precede reads and writes
`needkey` attribute-value-list
| 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.
`write` data
| send data from the other party to factotum. The possible replies are: `ok` the write succeeded `needkey` attribute-value-list
| see above
`toosmall` n
| the write is too short, get more data from the other party and retry the write. n specifies the maximun total number of bytes.
`phase` string
| its not your turn to write, get some data from factotum first.
`done` see above `done haveai`
| see above
`readhex`, `writehex`
| like `read` and `write`, except that an `ok` response to `readhex` returns the data encoded as a long hexadecimal string, and the argument to `writehex` is expected to be a long hexadecimal string. These are useful for manually debugging of binary protocols.
`authinfo`
| retrieve the AuthInfo structure. The possible replies are: `ok` data
| data
| is a marshaled form of the AuthInfo structure.
`error` string
| where string is the reason for the error.
`attr` retrieve the attributes used in the `start` RPC. The possible replies are:
| `ok` attribute-value-list `error` string
| where string is the reason for the error.
Protocols Factotum supports many authentication types, each with its own roles and required key attributes.
P9any, p9sk1, p9sk2, and p9cr are used to authenticate to Plan 9 systems; valid `role`s are `client` and `server`. All require `proto=p9sk1` keys with `user`, `dom` (authentication domain), and `!password` attributes.
P9sk1 and p9sk2 are the Plan 9 shared-key authentication protocols. P9sk2 is a deprecated form of p9sk1 that neglects to authenticate the server.
P9any is a meta-protocol that negotiates a protocol (`p9sk1` or `p9sk2`) and an authentication domain and then invokes the given protocol with a `dom=` attribute.
P9any, p9sk1, and p9sk2 are intended to be proxied via auth_proxy (see auth(3)).
P9cr is a textual challenge-response protocol; roles are `client` and `server`. It uses p9sk1 keys as described above. The protocol with factotum is textual: client writes a user name, server responds with a challenge, client writes a response, server responds with `ok` or `bad`. Typically this information is wrapped in other protocols before being sent over the network.
Vnc is the challenge-response protocol used by vnc(1); valid roles are `client` and `server`. The client protocol requires a `proto=vnc` key with attribute `!password`. Conventionally, client keys also have `user` and `server` attributes. The server protocol requires a p9sk1 key as described above. The protocol with factotum is the same as p9cr, except that the challenge and response are not textual.
Apop and cram are challenge-response protocols typically used to authenticate to mail servers. The client protocols require `proto=apop` or `proto=cram` keys with `user` and `!password` attributes. Conventionally, client keys also have `server` attributes. The server protocol requires a p9sk1 key as described above. The protocol with factotum is textual: server writes a challenge of the form random`@`domain, client responds with user name and then a hexadecimal response (two separate writes), and then the server responds with `ok` or `bad`.
Chap and mschap are challenge-response protocols used in PPP sessions; valid roles are `client` and `server`. The client protocols require `proto=chap` or `proto=mschap` keys with `user` and `!password` attributes. Conventionally, client keys also have `server` attributes. The server protocol requires a p9sk1 key as described above. The protocol with factotum is: server writes an 8-byte binary challenge, client responds with user name and then a `Chapreply` or `MSchapreply` structure (defined in `<auth.h> ).
` Pass is a client-only protocol that hands out passwords from `proto=pass` keys with `user` and `!password` attributes. The protocol is a single read that returns a string: a space-separated quoted user name and password that can be parsed with tokenize (see getfields(3)). Conventionally, client keys have distinguishing attributes like `service` and `server` that can be specified in the `start` message to select a key.
Wep is a client-only pseudo-protocol that initializes the encryption key on a wireless ethernet device. It uses `proto=wep` keys with `!key1`, `!key2`, or `!key3` attributes. The protocol with factotum is: the client writes a device name that must begin with `#l`. In response, factotum opens the device’s control file, sets the wireless secret using the key, and turns on encryption. If the key has an `essid` attribute, factotum uses it to set the wireless station ID.
Rsa is an implementation of the RSA protocol. Valid roles are `decrypt`, `encrypt`, `sign`, and `verify`. Rsa uses `proto=rsa` keys with `ek` and `n` attributes, large integers specifying the public half of the key. If a key is to be used for decryption or signing, then it must also have attributes `!p`, `!q`, `!kp`, `!kq`, `!c2`, and `!dk` specifying the private half of the key; see rsa(3). Conventionally, rsa keys also have `service` attributes specifying the context in which the key is used: `ssh` (SSH version 1), `ssh−rsa` (SSH version 2), or `tls` (SSL and TLS). If an SSH key has a `comment` attribute, that comment is presented to remote SSH servers during key negotiation. The protocol for encryption (decryption) is: write the message, then read back the encrypted (decrypted) form. The protocol for signing is: write a hash of the actual message, then read back the signature. The protocol for verifying a signature is: write the message hash, write the purported signature, then read back `ok` or `bad` telling whether the signature could be verified. The hash defaults to SHA1 but can be specified by a `hash` attribute on the key. Valid hash functions are `md5` and `sha1`. The hash function must be known to factotum because the signature encodes the type of hash used. The `encrypt` and `verify` operations are included as a convenience; factotum is not using any private information to perform them.
Dsa is an implementation of the NIST digital signature algorithm. Valid roles are `sign` and `verify`. It uses `proto=dsa` keys with `p`, `q`, `alpha`, and `key` attributes. If the key is to be used for signing, it must also have a `!secret` attribute; see dsa(3). Conventionally, dsa keys also have `service` attributes specifying the context in which the key is used: `ssh−dss` (SSH version 2) is the only one. If an SSH key has a `comment` attribute, that comment is presented to SSH servers during key negotiation. The protocol for signing and verifying is the same as the RSA protocol. Unlike rsa, the dsa protocol ignores the `hash` attribute; it always uses SHA1.
Httpdigest is a client-only MD5-based challenge-response protocol used in HTTP; see RFC 2617. It uses `proto=httpdigest` keys with `user`, `realm`, and `!password` attributes. The protocol with factotum is textual: write the challenge, read the response. The challenge is a string with three space-separated fields nonce, method, and uri, parseable with tokenize. The response is a hexadecimal string of length 32.
SOURCE
| `/usr/lib/plan9/src/cmd/auth/factotum`
SEE ALSO
| ssh-agent(1)