|
|
@@ -1,6 +1,6 @@
|
|
|
.TH AUTHSRV 6
|
|
|
.SH NAME
|
|
|
-ticket \- authentication service
|
|
|
+authsrv, p9any, p9sk1, p9sk2 \- authentication protocols
|
|
|
.SH DESCRIPTION
|
|
|
This manual page describes
|
|
|
the protocols used to authorize connections, confirm the identities
|
|
|
@@ -21,20 +21,26 @@ kernel running on that machine.
|
|
|
The domain name identifies the machines across which the ID is valid.
|
|
|
Together, the ID and domain name identify the owner of a key.
|
|
|
.PP
|
|
|
-When a terminal boots, the user is prompted for user name and password.
|
|
|
+When a terminal boots,
|
|
|
+.IR factotum (4)
|
|
|
+prompts for user name and password.
|
|
|
The user name becomes the terminal's authentication ID.
|
|
|
The password is converted using
|
|
|
.I passtokey
|
|
|
(see
|
|
|
-.IR auth (2))
|
|
|
-into a 56-bit DES key and saved as the machine's key.
|
|
|
+.IR authsrv (2))
|
|
|
+into a 56-bit DES key and saved in memory.
|
|
|
The authentication domain is set to the null string.
|
|
|
-If possible, the terminal validates the key with the AS
|
|
|
+If possible,
|
|
|
+.I factotum
|
|
|
+validates the key with the AS
|
|
|
before saving it.
|
|
|
For Internet machines the correct AS to ask is found using
|
|
|
.IR dhcpd (8).
|
|
|
.PP
|
|
|
-When a CPU or file server boots, it reads the key, ID, and domain name from
|
|
|
+When a CPU or file server boots,
|
|
|
+.I factotum
|
|
|
+reads the key, ID, and domain name from
|
|
|
non-volatile RAM.
|
|
|
This allows servers to reboot without operator intervention.
|
|
|
.PP
|
|
|
@@ -44,288 +50,361 @@ them one case at a time. The following definitions will be used
|
|
|
in the descriptions:
|
|
|
.TF nullx
|
|
|
.TP
|
|
|
-.I \fICHc\fP
|
|
|
-an 8-byte random challenge from a client
|
|
|
+.I Ks
|
|
|
+server's host ID's key
|
|
|
.TP
|
|
|
-.I CHs
|
|
|
-an 8-byte random challenge from a server
|
|
|
+.I Kc
|
|
|
+client's host ID's key
|
|
|
.TP
|
|
|
-.I \fIKs\fP
|
|
|
-server's key
|
|
|
+.I Kn
|
|
|
+a nonce key created for a ticket
|
|
|
+.RB ( key )
|
|
|
.TP
|
|
|
-.I \fIKc\fP
|
|
|
-client's key
|
|
|
+.IR K { m }
|
|
|
+message
|
|
|
+.I m
|
|
|
+encrypted with key
|
|
|
+.I K
|
|
|
.TP
|
|
|
-.I \fIKn\fP
|
|
|
-a nonce key created for a ticket
|
|
|
+.I CHc
|
|
|
+an 8-byte random challenge from a client
|
|
|
+.RB ( chal )
|
|
|
.TP
|
|
|
-.I K\fP\fIm\fP
|
|
|
-message m
|
|
|
-encrypted with key K
|
|
|
+.I CHs
|
|
|
+an 8-byte random challenge from a server
|
|
|
+.RB ( chal )
|
|
|
.TP
|
|
|
-.I \fIIDs\fP
|
|
|
+.I IDs
|
|
|
server's ID
|
|
|
+.RB ( authid )
|
|
|
.TP
|
|
|
-.I \fIDNs\fP
|
|
|
+.I DN
|
|
|
server's authentication domain name
|
|
|
+.RB ( authdom )
|
|
|
.TP
|
|
|
-.I \fIIDc\fP
|
|
|
+.I IDc
|
|
|
client's ID
|
|
|
+.RB ( hostid ,
|
|
|
+.BR cuid )
|
|
|
.TP
|
|
|
-.I \fIUIDc\fP
|
|
|
-user's name on the client
|
|
|
-.TP
|
|
|
-.I \fIUIDs\fP
|
|
|
-user's name on the server
|
|
|
+.I IDr
|
|
|
+client's desired ID on server
|
|
|
+.RB ( uid ,
|
|
|
+.BR suid )
|
|
|
.PD
|
|
|
.PP
|
|
|
-A number of constants defined in
|
|
|
-.B auth.h
|
|
|
-are also used:
|
|
|
-.IR AuthTreq,
|
|
|
-.IR AuthChal,
|
|
|
-.IR AuthOK,
|
|
|
-.IR AuthErr,
|
|
|
-.IR AuthTs,
|
|
|
-.IR AuthTc,
|
|
|
-.IR AuthAs,
|
|
|
+The parenthesized names are the ones used in the
|
|
|
+.B Ticketreq
|
|
|
and
|
|
|
-.IR AuthAc .
|
|
|
-.SS "File Service"
|
|
|
-File service sessions are long-lived connections between a client host
|
|
|
-and a file server.
|
|
|
-Processes belonging to different users share the session.
|
|
|
-Whenever a user process on the client
|
|
|
-.I mounts
|
|
|
-a file server
|
|
|
-(see
|
|
|
-.IR bind (2)),
|
|
|
-it must authenticate itself.
|
|
|
-There are four players in an authentication: the server, the client kernel,
|
|
|
-the user process on the client, and the authentication server.
|
|
|
-The goal of the authentication protocol is to convince the server
|
|
|
-that the client may validly speak for the user process.
|
|
|
-.PP
|
|
|
-To reduce the number of messages for each authentication,
|
|
|
-common information is exchanged once at the
|
|
|
-beginning of the session within a
|
|
|
-.I session
|
|
|
-message
|
|
|
-(see
|
|
|
-.IR attach (5)):
|
|
|
-.TF "Client->Server"
|
|
|
-.TP
|
|
|
-.IR Client -> Server
|
|
|
-Tsession( \fICHc\fP )
|
|
|
-.TP
|
|
|
-.IR Server -> Client
|
|
|
-Rsession( \fICHs\fP, \fIIDs\fP, \fIDNs\fP )
|
|
|
-.PD
|
|
|
-.PP
|
|
|
-Each time a user mounts a file server connection, an attach
|
|
|
-message is sent identifying/authenticating the user:
|
|
|
-.TF "Client->Server"
|
|
|
-.TP
|
|
|
-.IR Client -> Server
|
|
|
-Tattach( \fIKs\fP{ \fIAuthTs\fP, \fICHs\fP, \fIUIDc\fP, \fIUIDs\fP, \fIKn\fP }, \fIKn\fP{ \fIAuthAc\fP, \fICHs\fP, \fIcount\fP } )
|
|
|
-.TP
|
|
|
-.IR Server -> Client
|
|
|
-Rattach( \fIKn\fP{ AuthAs, \fICHc\fP, \fIcount\fP } )
|
|
|
-.PD
|
|
|
+.B Ticket
|
|
|
+structures in
|
|
|
+.BR <authsrv.h> .
|
|
|
.PP
|
|
|
-The part of the attach request encrypted with
|
|
|
-.BR \fIKs\fP
|
|
|
-is called a
|
|
|
-.IR ticket .
|
|
|
-Since it is encrypted in the server's secret key, this message is guaranteed
|
|
|
-to have originated on the AS.
|
|
|
-The part encrypted with the
|
|
|
-.B \fIKn\fP
|
|
|
-found in the ticket is called an
|
|
|
-.IR authenticator .
|
|
|
-The authenticator is generated by the client kernel and guarantees that
|
|
|
-the ticket was not stolen.
|
|
|
-The
|
|
|
-.I count
|
|
|
-is incremented with each mount to make every authenticator unique,
|
|
|
-thus foiling replay attacks.
|
|
|
-The server is itself authenticated by the authenticator
|
|
|
-it sends as a reply to the attach.
|
|
|
+The message type constants
|
|
|
+.IR AuthTreq ,
|
|
|
+.IR AuthChal ,
|
|
|
+.IR AuthPass ,
|
|
|
+.IR AuthOK ,
|
|
|
+.IR AuthErr ,
|
|
|
+.IR AuthMod ,
|
|
|
+.IR AuthApop ,
|
|
|
+.IR AuthOKvar ,
|
|
|
+.IR AuthChap ,
|
|
|
+.IR AuthMSchap ,
|
|
|
+.IR AuthCram ,
|
|
|
+and
|
|
|
+.IR AuthVNC
|
|
|
+.RB ( type )
|
|
|
+are defined in
|
|
|
+.BR <authsrv.h> ,
|
|
|
+as are the encrypted message types
|
|
|
+.IR AuthTs ,
|
|
|
+.IR AuthAs ,
|
|
|
+.IR AuthAc ,
|
|
|
+.IR AuthTp ,
|
|
|
+and
|
|
|
+.IR AuthHr
|
|
|
+.RB ( num ).
|
|
|
+.SS "Ticket Service
|
|
|
+When a client and server wish to authenticate to each other,
|
|
|
+they do so using
|
|
|
+.I tickets
|
|
|
+issued by the AS.
|
|
|
+Obtaining tickets from the AS
|
|
|
+is the client's responsibility.
|
|
|
.PP
|
|
|
-Tickets are created by the AS at the request of a user process.
|
|
|
-The AS contains a database of which \fIIDc\fP's may speak for which \fIUIDc\fP's.
|
|
|
-If the \fIIDc\fP may speak for the \fIUIDc\fP, two tickets are returned.
|
|
|
-.TF "UserProc->AS"
|
|
|
-.TP
|
|
|
-.IR UserProc -> AS
|
|
|
-\fIAuthTreq\fP, \fICHs\fP, \fIIDs\fP, \fIDNs\fP, \fIIDc\fP, \fIUIDc\fP
|
|
|
-.TP
|
|
|
-.IR AS -> UserProc
|
|
|
-\fIAuthOK\fP, \fIKc\fP{ \fIAuthTc\fP, \fICHs\fP, \fIUIDc\fP, \fIUIDs\fP, \fIKn\fP }, \fIKs\fP{ \fIAuthTs\fP, \fICHs\fP, \fIUIDc\fP, \fIUIDs\fP, \fIKn\fP }
|
|
|
-.PD
|
|
|
+The protocol to obtain a ticket pair is:
|
|
|
+.TP
|
|
|
+.IR C \(-> A
|
|
|
+.IR AuthTreq ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDr
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> C
|
|
|
+.IR AuthOK ,
|
|
|
+.IR Kc { AuthTc ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDr ,
|
|
|
+.IR Kn },
|
|
|
+.IR Ks { AuthTs ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDr ,
|
|
|
+.IR Kn }
|
|
|
.PP
|
|
|
-Otherwise an error message is returned.
|
|
|
-.TF "UserProc->AS"
|
|
|
-.TP
|
|
|
-.IR AS -> UserProc
|
|
|
-\fIAuthErr\fP, 64-byte error string
|
|
|
-.PD
|
|
|
+The two tickets are identical except for their type fields
|
|
|
+and the keys with which they are encrypted.
|
|
|
+The client and server can each decrypt one of the tickets,
|
|
|
+establishing a shared secret
|
|
|
+.IR Kn .
|
|
|
.PP
|
|
|
-The user passes both tickets to the client's kernel using
|
|
|
-the
|
|
|
-.I fauth
|
|
|
-system call
|
|
|
-(see
|
|
|
-.IR fauth (2)).
|
|
|
-The kernel decrypts the ticket encrypted with \fIKc\fP.
|
|
|
-If \fIUIDc\fP
|
|
|
-matches the user's login ID, the tickets are remembered for
|
|
|
-any subsequent attaches by that user of that file server session.
|
|
|
-Otherwise, the ticket is assumed stolen and an error is returned.
|
|
|
-.SS "Remote Execution"
|
|
|
+The
|
|
|
+tickets can be viewed as a statement by the
|
|
|
+AS that
|
|
|
+``a client possessing the
|
|
|
+.I Kn
|
|
|
+key is allowed to authenticate as
|
|
|
+.IR IDr .''
|
|
|
.PP
|
|
|
-A number of applications require a process on one machine to start
|
|
|
-a process with the same user ID on a server machine.
|
|
|
-Examples are
|
|
|
-.IR cpu (1),
|
|
|
-.I rx
|
|
|
-(see
|
|
|
-.IR con (1)),
|
|
|
-and
|
|
|
-.IR exportfs (4).
|
|
|
-The called process replies to the connection with a ticket request.
|
|
|
-.TF "Server->UserProc"
|
|
|
-.TP
|
|
|
-.IR Server -> UserProc
|
|
|
-\fIAuthTreq\fP, \fICHs\fP, \fIIDs\fP, \fIDNs\fP, xxx, xxx
|
|
|
-.PD
|
|
|
+The presence of the server challenge
|
|
|
+.I CHs
|
|
|
+in the ticket allows the server to verify the freshness
|
|
|
+of the ticket pair.
|
|
|
.PP
|
|
|
-Here
|
|
|
-.I xxx
|
|
|
-indicates a field whose contents do not matter.
|
|
|
+The AS sets the
|
|
|
+.I IDr
|
|
|
+in the tickets to the requested
|
|
|
+.I IDr
|
|
|
+only if
|
|
|
+.I IDc
|
|
|
+is allowed to
|
|
|
+.I "speak for
|
|
|
+.RI ( q.v. )
|
|
|
+.IR IDr .
|
|
|
+If not,
|
|
|
+the AS sets
|
|
|
+.I IDr
|
|
|
+to the empty string.
|
|
|
.PP
|
|
|
-The calling process adds its machine's \fIIDc\fP and its \fIUIDc\fP to the request
|
|
|
-and follows the protocol outlined above to get two tickets from the AS.
|
|
|
-The process passes the
|
|
|
-\fIKs\fP
|
|
|
-encrypted ticket plus an authenticator generated by
|
|
|
-.B /dev/authenticator
|
|
|
-from the
|
|
|
-\fIKc\fP
|
|
|
-ticket to the remote server, which writes them to the
|
|
|
-kernel to set the user ID (see
|
|
|
-.IR cons (3)).
|
|
|
-The server replies with its own authenticator which can be written
|
|
|
-to the kernel along with the
|
|
|
-\fIKc\fP
|
|
|
-encrypted ticket to confirm the server's identity (see
|
|
|
-.IR cons (3)).
|
|
|
-.TF "UserProc->Server"
|
|
|
-.TP
|
|
|
-.IR UserProc -> Server
|
|
|
-\fIKs\fP{ \fIAuthTs\fP, \fICHs\fP, \fIUIDc\fP, \fIUIDs\fP, \fIKn\fP }, \fIKn\fP{ \fIAuthAc\fP, \fICHs\fP, 0 }
|
|
|
-.TP
|
|
|
-.IR Server -> UserProc
|
|
|
-\fIKn\fP{ \fIAuthAs\fP, \fICHs\fP, 0 }
|
|
|
-.PD
|
|
|
-.SS "Challenge Box"
|
|
|
-A user may also start a process on a CPU server from a non Plan 9
|
|
|
-machine using commands such as
|
|
|
-.IR con,
|
|
|
-.IR telnet,
|
|
|
+If the users
|
|
|
+.I IDc
|
|
|
or
|
|
|
-.I ftp
|
|
|
-(see
|
|
|
-.IR con (1)
|
|
|
+.I IDs
|
|
|
+do not exist,
|
|
|
+the AS silently generates one-time
|
|
|
+random keys to use in place of
|
|
|
+.I Kc
|
|
|
+or
|
|
|
+.IR Ks ,
|
|
|
+so that clients cannot probe the AS
|
|
|
+to learn whether a user name is valid.
|
|
|
+.SS "P9sk1
|
|
|
+The Plan 9 shared key protocol
|
|
|
+.I p9sk1
|
|
|
+allows a client and server to authenticate each other.
|
|
|
+The protocol is:
|
|
|
+.TP
|
|
|
+.IR C \(-> S
|
|
|
+.I CHc
|
|
|
+.br
|
|
|
+The client starts by sending a random challenge to the server.
|
|
|
+.TP
|
|
|
+.IR S \(-> C
|
|
|
+.IR AuthTreq ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR \- ,
|
|
|
+.IR \-
|
|
|
+.br
|
|
|
+The server replies with a ticket request giving its
|
|
|
+id and authentication domain along with its own
|
|
|
+random challenge.
|
|
|
+.TP
|
|
|
+.IR C \(-> S
|
|
|
+.IR Ks { AuthTs ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDr ,
|
|
|
+.IR Kn },
|
|
|
+.IR Kn { AuthAc ,
|
|
|
+.IR CHs }
|
|
|
+.br
|
|
|
+The client adds
|
|
|
+.I IDc
|
|
|
and
|
|
|
-.IR ftpfs (4)).
|
|
|
-In these situations, the user can authenticate using a hand-held
|
|
|
-DES encryptor.
|
|
|
-The telnet or FTP daemon first sends a ticket request to the
|
|
|
-authentication server.
|
|
|
-If the AS has keys for both the \fIIDc\fP and \fIUIDc\fP in the ticket
|
|
|
-request it returns a challenge as a hexadecimal number.
|
|
|
-.TF "Daemon->AS"
|
|
|
-.TP
|
|
|
-.IR Daemon -> AS
|
|
|
-\fIAuthChal\fP, \fICHc\fP, \fIIDc\fP, \fIDNs\fP, \fIIDc\fP, \fIUIDc\fP
|
|
|
-.TP
|
|
|
-.IR AS -> Daemon
|
|
|
-\fIAuthOK\fP, 16-byte
|
|
|
-.SM ASCII
|
|
|
-challenge
|
|
|
+.I IDr
|
|
|
+to the ticket request and obtains a ticket pair
|
|
|
+from the AS as described above.
|
|
|
+The client relays the server's ticket along with
|
|
|
+an
|
|
|
+.IR authenticator ,
|
|
|
+the
|
|
|
+.I AuthAc
|
|
|
+message.
|
|
|
+The authenticator proves to the server that the
|
|
|
+client knows
|
|
|
+.I Kn
|
|
|
+and is therefore allowed to authenticate as
|
|
|
+.IR IDr .
|
|
|
+(The inclusion of
|
|
|
+.IR CHs
|
|
|
+in the authenticator avoids replay attacks.)
|
|
|
+.TP
|
|
|
+.IR S \(-> C
|
|
|
+.IR Kn { AuthAs ,
|
|
|
+.IR CHc }
|
|
|
+.br
|
|
|
+The server replies with its own authenticator,
|
|
|
+proving to the client that it also knows
|
|
|
+.I Kn
|
|
|
+and therefore
|
|
|
+.I Ks .
|
|
|
.PD
|
|
|
.PP
|
|
|
-Otherwise, it returns a null-terminated 64-byte error string.
|
|
|
-.TF "Daemon->AS"
|
|
|
-.TP
|
|
|
-.IR AS -> Daemon
|
|
|
-\fIAuthErr\fP, 64-byte error string
|
|
|
-.PD
|
|
|
+.I P9sk2
|
|
|
+is an older variant of
|
|
|
+.I p9sk1
|
|
|
+used only when connecting to pre-9P2000 remote
|
|
|
+execution services.
|
|
|
+It omits the first message and last
|
|
|
+messages and therefore does not
|
|
|
+authenticate the server to the client.
|
|
|
+.SS "P9any
|
|
|
+.I P9any
|
|
|
+is the standard Plan 9 authentication protocol.
|
|
|
+It consists of a negotiation to determine a common
|
|
|
+protocol, followed by the agreed-upon protocol.
|
|
|
.PP
|
|
|
-The daemon relays the challenge to the calling program,
|
|
|
-which displays the challenge on the user's screen.
|
|
|
-The user encrypts it and types in the
|
|
|
-result, which is relayed back to the AS.
|
|
|
-The AS checks it against the expected response and returns
|
|
|
-either a ticket or an error.
|
|
|
-.TF "Daemon->AS"
|
|
|
-.TP
|
|
|
-.IR Daemon -> AS
|
|
|
-16-byte
|
|
|
-.SM ASCII
|
|
|
-response
|
|
|
-.TP
|
|
|
-.IR AS -> Daemon
|
|
|
-\fIAuthOK\fP, \fIKc\fP{ \fIAuthTs\fP, \fICHc\fP, \fIUIDc\fP, \fIUIDc\fP, \fIKn\fP }
|
|
|
-.PD
|
|
|
+The negotiation protocol is:
|
|
|
+.TP
|
|
|
+.IR S \(-> C
|
|
|
+.B v.2
|
|
|
+.IB proto@authdom
|
|
|
+.IB proto@authdom
|
|
|
+.I ...
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR C \(-> S
|
|
|
+.I proto
|
|
|
+.I dom
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR S \(-> C
|
|
|
+.B OK
|
|
|
.PP
|
|
|
-or
|
|
|
-.TF "Daemon->AS"
|
|
|
-.TP
|
|
|
-.IR AS -> Daemon
|
|
|
-\fIAuthErr\fP, 64-byte error string
|
|
|
-.PD
|
|
|
+Each message is a NUL-terminated UTF string.
|
|
|
+The server begins by sending a list of
|
|
|
+.IR proto ,
|
|
|
+.I authdom
|
|
|
+pairs it is willing to use.
|
|
|
+The client
|
|
|
+responds with its choice.
|
|
|
+Requiring the client to wait for the final
|
|
|
+.B OK
|
|
|
+ensures that the client will not start
|
|
|
+the chosen protocol until the server is ready.
|
|
|
.PP
|
|
|
-Finally, the daemon passes the ticket to the kernel
|
|
|
-to set the user ID (see
|
|
|
-.IR cons (3)).
|
|
|
-.SS "Password Change"
|
|
|
-Any user can change the key stored for him or her on the AS.
|
|
|
-Once again we start by passing a ticket request to the AS.
|
|
|
-Only the user ID in the request is meaningful.
|
|
|
-The AS replies with a single ticket (or an error message)
|
|
|
-encrypted in the user's personal key.
|
|
|
-The user encrypts both the old and new keys with the
|
|
|
-\fIKn\fP from the returned ticket and sends that back to the AS.
|
|
|
-The AS checks the reply for validity and replies with an
|
|
|
-\fIAuthOK\fP byte or an error message.
|
|
|
-.TF "UserProc->AS"
|
|
|
-.TP
|
|
|
-.IR UserProc -> AS
|
|
|
-\fIAuthPass\fP, xxx, xxx, xxx, xxx, \fIUIDc\fP
|
|
|
-.TP
|
|
|
-.IR AS -> UserProc
|
|
|
-\fIAuthOK\fP, \fIKc\fP{ \fIAuthTp\fR, xxx, xxx, xxx, \fIKn\fP }
|
|
|
-.TP
|
|
|
-.IR UserProc -> AS
|
|
|
-\fIKn\fP{ \fIAuthPass\fP, "old password", "new password" }
|
|
|
-.TP
|
|
|
-.IR AS -> UserProc
|
|
|
-\fIAuthOK\fP
|
|
|
-.PD
|
|
|
+The above is version 2 of the protocol.
|
|
|
+Version 1,
|
|
|
+no longer used,
|
|
|
+omitted the first message's
|
|
|
+.B v.2
|
|
|
+prefix
|
|
|
+and the
|
|
|
+.B OK
|
|
|
+message.
|
|
|
.PP
|
|
|
+The
|
|
|
+.I p9any
|
|
|
+protocol is the protocol used by all
|
|
|
+Plan 9 services.
|
|
|
+The file server runs it over special
|
|
|
+authentication files
|
|
|
+(see
|
|
|
+.IR fauth (2)
|
|
|
+and
|
|
|
+.IR attach (5)).
|
|
|
+Other services, such as
|
|
|
+.IR cpu (1)
|
|
|
+and
|
|
|
+.IR exportfs (4),
|
|
|
+run
|
|
|
+.I p9any
|
|
|
+over the network and then
|
|
|
+use
|
|
|
+.I Kn
|
|
|
+to derive an
|
|
|
+.IR ssl (3)
|
|
|
+key to encrypt the rest of their communications.
|
|
|
+.SS "Password Change
|
|
|
+Users connect directly to the AS
|
|
|
+to change their passwords.
|
|
|
+The protocol is:
|
|
|
+.TP
|
|
|
+.IR C \(-> A
|
|
|
+.IR AuthPass ,
|
|
|
+.IR IDc ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHc ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDc
|
|
|
+.br
|
|
|
+The client sends a password change ticket request.
|
|
|
+.TP
|
|
|
+.IR A \(-> C
|
|
|
+.IR Kc { AuthTp ,
|
|
|
+.IR CHc ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDc ,
|
|
|
+.IR Kn }
|
|
|
+.br
|
|
|
+The server responds with a ticket containing the key
|
|
|
+.I Kn
|
|
|
+encrypted with the client's key
|
|
|
+.IR Kc
|
|
|
+.TP
|
|
|
+.IR C \(-> A
|
|
|
+.IR Kn { AuthPass ,
|
|
|
+.IR old ,
|
|
|
+.IR new ,
|
|
|
+.IR changesecret ,
|
|
|
+.IR secret }
|
|
|
+.br
|
|
|
+The client decrypts the ticket using the old password
|
|
|
+and then sends back an encrypted password request
|
|
|
+.RB ( Passwordreq
|
|
|
+structure)
|
|
|
+containing the old password and the new password.
|
|
|
+If
|
|
|
+.I changesecret
|
|
|
+is set, the AS also changes
|
|
|
+the user's
|
|
|
+.IR secret ,
|
|
|
+the password used for non-Plan 9 authentications.
|
|
|
+.TP
|
|
|
+.IR A \(-> C
|
|
|
+.I AuthOK
|
|
|
or
|
|
|
-.TF "UserProc->AS"
|
|
|
-.TP
|
|
|
-.IR AS -> UserProc
|
|
|
-\fIAuthErr\fP, 64-byte error string
|
|
|
-.PD
|
|
|
-.PP
|
|
|
-.SS "Data Base"
|
|
|
+.IR AuthErr ,
|
|
|
+64-byte error message
|
|
|
+.br
|
|
|
+The AS responds with simply
|
|
|
+.I AuthOK
|
|
|
+or with
|
|
|
+.I AuthErr
|
|
|
+followed by a 64-byte error message.
|
|
|
+.SS "Authentication Database
|
|
|
An
|
|
|
.IR ndb (2)
|
|
|
-database file exists for the authentication server.
|
|
|
+database file
|
|
|
+.B /lib/ndb/auth
|
|
|
+exists for the AS.
|
|
|
This database maintains ``speaks for'' relationships, i.e.,
|
|
|
it lists which users may speak for other users when
|
|
|
authtenticating.
|
|
|
@@ -360,43 +439,274 @@ may speak for any user except
|
|
|
.B sys
|
|
|
and
|
|
|
.BR adm .
|
|
|
-This property is used heavily on cpu servers.
|
|
|
+This property is used heavily on CPU servers.
|
|
|
+.SS "Foreign Protocols
|
|
|
+The AS accepts ticket request
|
|
|
+messages of types other than
|
|
|
+.I AuthTreq
|
|
|
+to allow users to
|
|
|
+authenticate using non-Plan 9 protocols.
|
|
|
+In these situations, the server communicates
|
|
|
+directly with the AS.
|
|
|
+Some protocols must begin without knowing the
|
|
|
+client's name. They ignore the client name in the
|
|
|
+ticket request.
|
|
|
+All the protocols end
|
|
|
+with the AS sending
|
|
|
+an
|
|
|
+.I AuthOK
|
|
|
+message containing a server ticket and authenticator.
|
|
|
.PP
|
|
|
-The
|
|
|
-.I ndb
|
|
|
-database is also used when talking to Lucent Radius
|
|
|
-servers to check SecureID authentications. The database
|
|
|
-file provides the Radius server's secret key and
|
|
|
-to mappings from local uid's to those known by the server.
|
|
|
-The attribute type
|
|
|
-.B radius
|
|
|
-identifies the Radius server.
|
|
|
-The attribute
|
|
|
-.B secret
|
|
|
-provides the hash key used in talking to the
|
|
|
-server.
|
|
|
-The attributes
|
|
|
-.B uid
|
|
|
-and
|
|
|
-.B rid
|
|
|
-profile the local and remote user id's when verifying
|
|
|
-a SecureID login.
|
|
|
-For example:
|
|
|
+.I AuthOK
|
|
|
+messages
|
|
|
+always have a fixed but context-dependent size.
|
|
|
+The occasional variable-length OK message starts with a
|
|
|
+.I AuthOKvar
|
|
|
+byte and a five-byte space-padded decimal length of the
|
|
|
+data that follows.
|
|
|
+.PP
|
|
|
+Anywhere an
|
|
|
+.I AuthOK
|
|
|
+message is expected, a
|
|
|
+.I AuthErr
|
|
|
+message may be substituted.
|
|
|
+.de Ok
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> S
|
|
|
+.IR AuthOK ,
|
|
|
+.IR Ks { \\$1 ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDs ,
|
|
|
+.IR IDc ,
|
|
|
+.IR Kn },
|
|
|
+.IR Kn { AuthTs ,
|
|
|
+.IR CHs }
|
|
|
+..
|
|
|
.PP
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR AuthChal ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDs ,
|
|
|
+.IR IDc
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> S
|
|
|
+.IR AuthOK ,
|
|
|
+.IR challenge
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR response
|
|
|
+.Ok AuthChal
|
|
|
+.IP
|
|
|
+This protocol allows the use of
|
|
|
+handheld authenticators such as SecureNet
|
|
|
+keys and SecureID tokens
|
|
|
+in programs such as
|
|
|
+.IR ssh (1)
|
|
|
+and
|
|
|
+.I ftpd
|
|
|
+(see
|
|
|
+.IR ipserv (8)).
|
|
|
+.IP
|
|
|
+.I Challenge
|
|
|
+and
|
|
|
+.I response
|
|
|
+are text strings,
|
|
|
+.SM NUL -padded
|
|
|
+to 16 bytes
|
|
|
+.RB ( NETCHLEN ).
|
|
|
+The
|
|
|
+.I challenge
|
|
|
+is a random five-digit decimal number.
|
|
|
+When using a SecureNet key or
|
|
|
+.IR netkey (1),
|
|
|
+the
|
|
|
+.I response
|
|
|
+is an eight-digit decimal or hexadecimal number
|
|
|
+that is an encryption of the challenge
|
|
|
+using the user's DES key.
|
|
|
+.IP
|
|
|
+When using a SecureID token,
|
|
|
+the challenge is ignored.
|
|
|
+The response is the user's PIN followed by
|
|
|
+the six-digit number currently displayed
|
|
|
+on the token.
|
|
|
+In this case, the AS
|
|
|
+queries an external RADIUS server
|
|
|
+to check the response.
|
|
|
+Use of a RADIUS server requires an entry in
|
|
|
+the authentication database. For example:
|
|
|
+.IP
|
|
|
.EX
|
|
|
-radius=lra-radius secret=xyzzy
|
|
|
- uid=bob rid=roberttheworkstation
|
|
|
+ radius=server-name secret=xyzzy
|
|
|
+ uid=howard rid=trickey
|
|
|
+ uid=sape rid=smullender
|
|
|
.EE
|
|
|
-.PP
|
|
|
-says that when verifying SecureID's on server
|
|
|
-.BR lra-radius ,
|
|
|
-use the hash key
|
|
|
-.BR xyzzy .
|
|
|
-Local user
|
|
|
-.B bob
|
|
|
-is known as
|
|
|
-.B roberttheworkstation
|
|
|
-on the radius server.
|
|
|
+.IP
|
|
|
+In this example, the secret
|
|
|
+.B xyzzy
|
|
|
+is the hash key used in talking to the RADIUS server.
|
|
|
+The
|
|
|
+.BR uid / rid
|
|
|
+lines map from Plan 9 user ids to RADIUS ids.
|
|
|
+Users not listed are assumed to have the
|
|
|
+same id in both places.
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+AuthApop ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR \- ,
|
|
|
+.IR \-
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> S
|
|
|
+.IR AuthOKvar ,
|
|
|
+.IR challenge
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+AuthApop ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDc ,
|
|
|
+.IR IDc ;
|
|
|
+hexadecimal MD5 checksum
|
|
|
+.Ok AuthApop
|
|
|
+.IP
|
|
|
+This protocol implements APOP authentication
|
|
|
+(see
|
|
|
+.IR pop3 (8)).
|
|
|
+After receiving a ticket request of type
|
|
|
+.IR AuthApop ,
|
|
|
+the AS generates a random challenge
|
|
|
+of the form
|
|
|
+.BI < random @ domain >\fR.
|
|
|
+The client then replies with a new ticket request
|
|
|
+giving the user name
|
|
|
+followed by the MD5 checksum of
|
|
|
+the challenge concatenated with the user's secret.
|
|
|
+If the response is correct, the authentication
|
|
|
+server sends back a ticket
|
|
|
+and authenticator.
|
|
|
+If the response is incorrect, the client may repeat the
|
|
|
+ticket request/MD5 checksum message to try again.
|
|
|
+.IP
|
|
|
+The
|
|
|
+.I AuthCram
|
|
|
+protocol runs identically to the
|
|
|
+.I AuthApop
|
|
|
+protocol, except that the expected MD5 checksum
|
|
|
+is the keyed MD5 hash using the user's secret as the key
|
|
|
+(see
|
|
|
+.I hmac_md5
|
|
|
+in
|
|
|
+.IR sechash (2)).
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR AuthChap ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR \- ,
|
|
|
+.IR \-
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> S
|
|
|
+.I challenge
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR pktid ,
|
|
|
+.IR IDc ,
|
|
|
+.IR response
|
|
|
+.Ok AuthChap
|
|
|
+.IP
|
|
|
+This protocol implements CHAP authentication
|
|
|
+(see
|
|
|
+.IR ppp (8)).
|
|
|
+The
|
|
|
+.I challenge
|
|
|
+is eight random bytes.
|
|
|
+The response is a 16-byte MD5 checksum
|
|
|
+over the packet id, user's secret, and challenge.
|
|
|
+The reply packet is defined as
|
|
|
+.B OChapreply
|
|
|
+in
|
|
|
+.BR <authsrv.h> .
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR AuthMSchap ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR \- ,
|
|
|
+.IR \-
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> S
|
|
|
+.I challenge
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR IDc ,
|
|
|
+.IR lm-response ,
|
|
|
+.IR nt-response
|
|
|
+.Ok AuthMschap
|
|
|
+.IP
|
|
|
+This protocol implements Microsoft's MS-CHAP
|
|
|
+authentication
|
|
|
+(see
|
|
|
+.IR ppp (8)).
|
|
|
+The
|
|
|
+.I challenge
|
|
|
+is eight random bytes.
|
|
|
+The two responses are Microsofts LM and NT hashes.
|
|
|
+Only the NT hash may be used to authenticate,
|
|
|
+as the LM hash is considered too weak.
|
|
|
+The reply packet is defined as
|
|
|
+.B OMSchapreply
|
|
|
+in
|
|
|
+.BR <authsrv.h> .
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.IR AuthVNC ,
|
|
|
+.IR IDs ,
|
|
|
+.IR DN ,
|
|
|
+.IR CHs ,
|
|
|
+.IR IDs ,
|
|
|
+.IR IDc
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR A \(-> S
|
|
|
+.IR AuthOKvar ,
|
|
|
+.I challenge
|
|
|
+.sp -\n(PDu
|
|
|
+.TP
|
|
|
+.IR S \(-> A
|
|
|
+.I response
|
|
|
+.Ok
|
|
|
+.IP
|
|
|
+This protocol implements VNC authentication
|
|
|
+(see
|
|
|
+.I vncs
|
|
|
+in
|
|
|
+.IR vnc (1)).
|
|
|
+The challenge is 16 random bytes, and the response
|
|
|
+is a DES ECB encryption of the challenge.
|
|
|
+The method by which VNC converts the user's
|
|
|
+secret into a DES key is weak,
|
|
|
+considering only the first eight bytes of the secret.
|
|
|
+.PD
|
|
|
.SH FILES
|
|
|
.TF /lib/ndb/auth.*xxx
|
|
|
.TP
|
David du Colombier