1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
<!DOCTYPE html>
<html lang=en>
<head>
<title></title>
<meta charset="utf-8"/>
<link rel="shortcut icon" href="favicon.ico"/>
<link rel='stylesheet' type='text/css' href='style.css'/>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<header><h1 class=pagetop>Projects</h1></header>
<main>
<h2>mfa</h2>
<p><em>Check out the source code here - </em>
<a href=https://git.chudnick.com/mfa>git.chudnick.com/mfa</a></p>
<p><strong>mfa</strong> is a system for out-of-band multi-factor
authentication with PAM.
My original reason for working on this was to get MFA functionality for
a Postfix/Dovecot mail server that uses PAM for authentication.
Solutions such as pam_oath are not feasible
for this purpose because a mail client has no way of exposing an
interface for the oath challenge-response.
Therefore a way to circumvent the original application to get the request
to the user is needed, which is what mfa does.</p>
<p>The design of mfa is not novel, it works the same way as Cisco's Duo.
Duo does have open source modules for achieving this objective, but all
the authentication requests are
sent back to their proprietary "cloud" service. I'm sure that most
free software
enthusiasts see this as a major red flag, especially for small personal
use cases.</p>
<h3>Design</h3>
<p>mfa is primarily composed of three parts - the server, the client,
and the PAM module.
The server listens for connections from both clients and PAM
modules. The server receives a
request from a PAM module that includes the username of the user
attempting to authenticate,
the hostname of the computer, and the service being accessed. The
server then correlates the
combination of user, host, and service to a particular client, and
attempts to push a request.
The server will then evaluate the client's response, and either
return to the PAM module that
the user is authenticated or denied.</p>
<p>The server itself consists of two parts that I've called
<strong>mfad</strong> and
<strong>mfac</strong>. mfad is the program responsible for doing
what I've described above.
mfac is a command line utility that the administrator uses to
configure the server. mfac is used
to enroll clients in the system and to provision applications. A
client is enrolled by using the
--add-client option and providing an alias for that user. The
server then assigns that user an
identifying key that is used to connect and a TOTP secret key. With
the client enrolled, the
administrator can then assign applications to that client. With the
--add-app command, the
administrator ties a username, hostname, and service combination to
a client alias, so that
when that combination is seen the server knows who to ask for
authentication. The administrator
also identifies which MFA methods are valid for this combination
(currently either or both of
push and/or totp). The example below shows the process of
enrolling a new client called
'tux' and then provisioning MFA for SSH attempts to
tux@linux.example.org.</p>
<pre><code><em># Enroll a client named tux</em>
mfac --add-client tux
alias: tux
client key: VA32LB3SF2HG2FDWJS5XIOFVWTMBQYRSQ3PK3OOPA3FBIQMSMJZCXYJQCYKYUWUU
totp secret: TGGG3QCXA4MR2S2X6B33GSYN
uri: otpauth://totp/tux%40mfad?secret=TGGG3QCXA4MR2S2X6B33GSYN
<em># Provision MFA for SSH tux@linux.example.org allowing for both push
authentication or TOTP</em>
mfac --add-app --user tux --host linux.example.org --service sshd --alias tux
--methods push totp
</code></pre>
<p>The PAM module of mfa also consists of two parts: the actual PAM
module
<strong>pam_mfa.so</strong> that gets called in the PAM stack and a
helper
program that interacts with mfad. The job of pam_mfa.so is to
retrieve the
necessary information (user and service) from PAM and then invoke
the helper
program with that data. It then waits for the MFA process to
complete, retrieves
the result, and returns either success or failure to the PAM stack.
The helper
program initiates a connetion to mfad when run and then passes
username, hostname,
and service information to the server. It too receives a success
or failure response
and then relays that information to the PAM module. Here is an
example of using
pam_mfa.so in the PAM stack for sshd.</p>
<pre><code><strong>/etc/pam.d/sshd</strong>
auth requisite pam_mfa.so</code></pre>
<p>The client program is what the end user interacts with to
provide authentication responses.
Currently it is only a very simple terminal program but expanding
on this is high on the
TODO list. The client opens a connection to the server and
identifies itself with the client
key that was generated during enrollment. The client waits for a
prompt from the server, and
when it receives one, informs the user. The client receives the
users input and sends it back
to the server. The client performs this loop continuously until it
is closed.</p>
<h2>clibrary</h2>
<p><em>Check out the source code here -</em>
<a href=https://git.chudnick.com/clibrary>git.chudnick.com/clibrary</a></p>
<h2>mail-tools</h2>
<p>
<a href=https://git.chudnick.com/mail-tools>git.chudnick.com/mail-tools</a>
</p>
<h2>deploy-scripts</h2>
<p>
<a href=https://git.chudnick.com/deploy-scripts>
git.chudnick.com/deploy-scripts</a>
</p>
<h2>server-scripts</h2>
<p>
<a href=https://git.chudnick.com/server-scripts>
git.chudnick.com/server-scripts</a>
</p>
</main>
<footer><a href=index.html>www.chudnick.com</a></footer>
</body>
</html>
|
