1
00:00:00,000 --> 00:00:08,469
foreign

2
00:00:00,500 --> 00:00:08,469
[Music]

3
00:00:11,519 --> 00:00:16,440
good morning and our next talk is from

4
00:00:13,980 --> 00:00:19,619
Fraser tweedale and he'll be talking on

5
00:00:16,440 --> 00:00:22,020
Kerberos PK in it what why and how to

6
00:00:19,619 --> 00:00:24,539
break it Fraser works on identity

7
00:00:22,020 --> 00:00:26,400
management and PKR Solutions at Red Hat

8
00:00:24,539 --> 00:00:28,439
they are passionate about functional

9
00:00:26,400 --> 00:00:30,119
programming and security and enjoys

10
00:00:28,439 --> 00:00:32,759
playing with those little plastic bricks

11
00:00:30,119 --> 00:00:35,219
from Denmark today's talk by Fraser will

12
00:00:32,759 --> 00:00:37,140
focus on PK in it a Kerberos extension

13
00:00:35,219 --> 00:00:39,840
that replaces password authentication

14
00:00:37,140 --> 00:00:42,500
and x509 certificates please welcome

15
00:00:39,840 --> 00:00:45,500
Fraser

16
00:00:42,500 --> 00:00:45,500
thank you

17
00:00:48,480 --> 00:00:53,640
good morning

18
00:00:49,980 --> 00:00:57,059
thank you for coming to my talk

19
00:00:53,640 --> 00:01:00,899
so we're going to look at the Kerberos

20
00:00:57,059 --> 00:01:04,379
Authentication Protocol a brief overview

21
00:01:00,899 --> 00:01:06,119
of how that protocol works

22
00:01:04,379 --> 00:01:08,820
then

23
00:01:06,119 --> 00:01:11,700
we will look at the PK init protocol

24
00:01:08,820 --> 00:01:14,580
extension

25
00:01:11,700 --> 00:01:15,659
an overview of how that works and some

26
00:01:14,580 --> 00:01:18,240
demos

27
00:01:15,659 --> 00:01:22,200
I will discuss PK init security

28
00:01:18,240 --> 00:01:25,560
considerations and I will demonstrate a

29
00:01:22,200 --> 00:01:28,799
vulnerability in free ipas

30
00:01:25,560 --> 00:01:31,439
implementation of PK init which I

31
00:01:28,799 --> 00:01:34,220
discovered late last year and which has

32
00:01:31,439 --> 00:01:34,220
now been fixed

33
00:01:34,500 --> 00:01:41,220
so Kerberos is an Authentication

34
00:01:36,840 --> 00:01:43,500
Protocol based on symmetric cryptography

35
00:01:41,220 --> 00:01:46,560
it's a single sign-on protocol which

36
00:01:43,500 --> 00:01:50,159
means that you can authenticate once

37
00:01:46,560 --> 00:01:52,140
and you have a session for a

38
00:01:50,159 --> 00:01:54,659
configurable duration for example one

39
00:01:52,140 --> 00:01:57,119
day and using that

40
00:01:54,659 --> 00:02:00,119
token from the initial authentication

41
00:01:57,119 --> 00:02:03,060
you'll be able to also authenticate to

42
00:02:00,119 --> 00:02:04,619
the various services or hosts that you

43
00:02:03,060 --> 00:02:07,200
may need to access

44
00:02:04,619 --> 00:02:09,420
Kerberos is typically deployed in

45
00:02:07,200 --> 00:02:12,420
Enterprise environments so the idea is

46
00:02:09,420 --> 00:02:15,080
coming at the start of the day log in

47
00:02:12,420 --> 00:02:17,640
once and you no longer need to log in

48
00:02:15,080 --> 00:02:21,060
throughout the day reducing password

49
00:02:17,640 --> 00:02:22,680
fatigue eliminating silos of passwords

50
00:02:21,060 --> 00:02:26,640
or identities across the business

51
00:02:22,680 --> 00:02:30,560
applications in the organization

52
00:02:26,640 --> 00:02:33,239
Kerberos emerged from MIT in the late

53
00:02:30,560 --> 00:02:35,819
1980s the current version of the

54
00:02:33,239 --> 00:02:38,220
protocol modulo the various extensions

55
00:02:35,819 --> 00:02:41,099
which had been defined but the core

56
00:02:38,220 --> 00:02:45,480
protocol version 5 is the main one in

57
00:02:41,099 --> 00:02:48,660
use today that one was defined in 1993.

58
00:02:45,480 --> 00:02:51,900
and the most recent RFC

59
00:02:48,660 --> 00:02:56,040
defining the core protocol is RFC 4120

60
00:02:51,900 --> 00:02:58,860
which was published in 2005.

61
00:02:56,040 --> 00:03:01,560
the major implementations of kerberus

62
00:02:58,860 --> 00:03:04,739
are MIT kerberus this was the original

63
00:03:01,560 --> 00:03:07,019
and is still one of the most prevalent

64
00:03:04,739 --> 00:03:09,780
or widely deployed Kerberos

65
00:03:07,019 --> 00:03:11,459
implementations Microsoft active

66
00:03:09,780 --> 00:03:14,220
directory of course is very widely

67
00:03:11,459 --> 00:03:17,340
deployed and used in many many

68
00:03:14,220 --> 00:03:20,220
organizations it also uses Kerberos

69
00:03:17,340 --> 00:03:23,760
Heimdall is an alternative free software

70
00:03:20,220 --> 00:03:25,080
implementation it's used in the bsds and

71
00:03:23,760 --> 00:03:28,560
elsewhere

72
00:03:25,080 --> 00:03:30,959
and free IPA or identity management in

73
00:03:28,560 --> 00:03:33,360
Rel is a centralized identity management

74
00:03:30,959 --> 00:03:34,560
solution that I have worked on at Red

75
00:03:33,360 --> 00:03:39,060
Hat

76
00:03:34,560 --> 00:03:42,019
and it includes MIT Kerberos with some

77
00:03:39,060 --> 00:03:42,019
additional extensions

78
00:03:43,319 --> 00:03:49,620
so the parties in the Kerberos protocol

79
00:03:46,140 --> 00:03:51,720
are the client who wants to authenticate

80
00:03:49,620 --> 00:03:54,120
two services

81
00:03:51,720 --> 00:03:58,280
the key distribution center

82
00:03:54,120 --> 00:04:01,140
which is a single service

83
00:03:58,280 --> 00:04:03,299
containing a record of all of the

84
00:04:01,140 --> 00:04:05,940
identities or principles

85
00:04:03,299 --> 00:04:08,040
that have been defined in that Realm

86
00:04:05,940 --> 00:04:10,200
and the services

87
00:04:08,040 --> 00:04:12,180
that the clients may wish to

88
00:04:10,200 --> 00:04:15,900
authenticate to

89
00:04:12,180 --> 00:04:18,180
services are also principles so KDC is

90
00:04:15,900 --> 00:04:21,479
the key distribution center it contains

91
00:04:18,180 --> 00:04:23,100
two conceptually distinct Services the

92
00:04:21,479 --> 00:04:25,680
authentication Service and the ticket

93
00:04:23,100 --> 00:04:28,680
granting service these could actually be

94
00:04:25,680 --> 00:04:33,360
separate hosts or separate distinct

95
00:04:28,680 --> 00:04:35,759
programs but typically they are

96
00:04:33,360 --> 00:04:38,340
provided together as part of a single

97
00:04:35,759 --> 00:04:41,100
service which we call the KDC

98
00:04:38,340 --> 00:04:45,060
the users the services and the KDC

99
00:04:41,100 --> 00:04:47,460
itself are represented as principles in

100
00:04:45,060 --> 00:04:49,919
an authentication Realm

101
00:04:47,460 --> 00:04:52,699
so if you as a user

102
00:04:49,919 --> 00:04:56,000
want to log in you can be you know Bob

103
00:04:52,699 --> 00:04:58,919
or Bob Smith at

104
00:04:56,000 --> 00:05:02,040
bobswidgets.com so the round part would

105
00:04:58,919 --> 00:05:02,040
be bobswidgets.com

106
00:05:02,460 --> 00:05:06,240
each principle has a long-term secret

107
00:05:04,979 --> 00:05:07,860
key

108
00:05:06,240 --> 00:05:11,639
which is known

109
00:05:07,860 --> 00:05:12,600
to the the principal uh the user or a

110
00:05:11,639 --> 00:05:17,040
host

111
00:05:12,600 --> 00:05:19,380
and the KDC also has a copy of this key

112
00:05:17,040 --> 00:05:22,199
so users typically derive their key from

113
00:05:19,380 --> 00:05:25,080
a password using a password-based key

114
00:05:22,199 --> 00:05:27,720
derivation algorithm

115
00:05:25,080 --> 00:05:28,940
and hosts or Services typically stored

116
00:05:27,720 --> 00:05:32,039
in a file

117
00:05:28,940 --> 00:05:33,840
containing lists one or more of these

118
00:05:32,039 --> 00:05:38,039
secret keys and those files are usually

119
00:05:33,840 --> 00:05:41,460
called a key tab or a key table

120
00:05:38,039 --> 00:05:45,360
the result of an Authentication

121
00:05:41,460 --> 00:05:47,759
is called a ticket and the client

122
00:05:45,360 --> 00:05:49,560
program on the user's behalf or on the

123
00:05:47,759 --> 00:05:53,639
principal's behalf will keep a record of

124
00:05:49,560 --> 00:05:54,720
that ticket for the validity duration of

125
00:05:53,639 --> 00:05:56,880
that ticket

126
00:05:54,720 --> 00:05:59,940
depending on the KDC configuration

127
00:05:56,880 --> 00:06:02,460
tickets can also be renewed without an

128
00:05:59,940 --> 00:06:05,960
additional authentication exchange but

129
00:06:02,460 --> 00:06:05,960
that is a matter of policy

130
00:06:06,120 --> 00:06:11,340
so uh trying to represent how Kurt Ross

131
00:06:09,240 --> 00:06:14,220
Works in diagram form here are the three

132
00:06:11,340 --> 00:06:17,820
parties client server and KDC

133
00:06:14,220 --> 00:06:18,960
the client has a copy of its key

134
00:06:17,820 --> 00:06:20,940
or

135
00:06:18,960 --> 00:06:22,560
knows a secret from which it can derive

136
00:06:20,940 --> 00:06:25,919
that same key

137
00:06:22,560 --> 00:06:27,120
the server also has its key the KDC has

138
00:06:25,919 --> 00:06:29,520
its own key a key for the ticket

139
00:06:27,120 --> 00:06:33,380
granting Service as well as the keys for

140
00:06:29,520 --> 00:06:33,380
all of the principles in the realm

141
00:06:33,780 --> 00:06:39,060
so the initial authentication is between

142
00:06:36,780 --> 00:06:41,580
the client and the KDC that's called the

143
00:06:39,060 --> 00:06:43,819
authentication Service exchange and in

144
00:06:41,580 --> 00:06:47,940
the authentication Service or as request

145
00:06:43,819 --> 00:06:50,960
the client says to the KDC hey it's me

146
00:06:47,940 --> 00:06:54,080
client it's me Bob or whoever

147
00:06:50,960 --> 00:06:56,419
and there's actually no

148
00:06:54,080 --> 00:06:59,580
authentication

149
00:06:56,419 --> 00:07:03,180
proof carried in this message the client

150
00:06:59,580 --> 00:07:04,259
just says it's me and the KDC sends a

151
00:07:03,180 --> 00:07:08,539
reply

152
00:07:04,259 --> 00:07:12,199
which contains a session key so that's

153
00:07:08,539 --> 00:07:15,500
R-1 which is randomly generated

154
00:07:12,199 --> 00:07:19,020
encrypted to the client's shared secret

155
00:07:15,500 --> 00:07:21,120
and it contains what we call a ticket

156
00:07:19,020 --> 00:07:23,580
granting ticket

157
00:07:21,120 --> 00:07:25,500
which also contains a copy of that

158
00:07:23,580 --> 00:07:29,479
session key as well as some client

159
00:07:25,500 --> 00:07:33,000
information and that is encrypted to the

160
00:07:29,479 --> 00:07:35,300
shared secret of the ticket granting

161
00:07:33,000 --> 00:07:35,300
service

162
00:07:36,720 --> 00:07:40,380
so after processing the authentication

163
00:07:39,060 --> 00:07:42,840
Service

164
00:07:40,380 --> 00:07:46,440
response or as rep

165
00:07:42,840 --> 00:07:47,960
the client decrypts the session key if

166
00:07:46,440 --> 00:07:50,520
that fails then

167
00:07:47,960 --> 00:07:53,400
you know it can't if it can't decrypt it

168
00:07:50,520 --> 00:07:55,919
then it wasn't Bob or it wasn't the user

169
00:07:53,400 --> 00:07:58,860
that the client said it was

170
00:07:55,919 --> 00:08:00,900
so that's where the proof of identity

171
00:07:58,860 --> 00:08:03,360
comes even though there's no proof of

172
00:08:00,900 --> 00:08:07,979
identity in the request itself

173
00:08:03,360 --> 00:08:11,460
and it stores the TGT for later use

174
00:08:07,979 --> 00:08:13,319
now when the client wants to talk to a

175
00:08:11,460 --> 00:08:16,199
server or a service

176
00:08:13,319 --> 00:08:17,699
it sends a TGs ticket granting service

177
00:08:16,199 --> 00:08:21,000
request

178
00:08:17,699 --> 00:08:23,759
and it says hello I would like to talk

179
00:08:21,000 --> 00:08:27,900
to such and such a service

180
00:08:23,759 --> 00:08:29,759
and it includes in its request the

181
00:08:27,900 --> 00:08:31,259
ticket granting ticket which it had

182
00:08:29,759 --> 00:08:34,320
previously stored

183
00:08:31,259 --> 00:08:36,360
as well as an authenticator encrypted

184
00:08:34,320 --> 00:08:38,880
with the session key

185
00:08:36,360 --> 00:08:41,219
which includes some client information

186
00:08:38,880 --> 00:08:46,399
and a timestamp

187
00:08:41,219 --> 00:08:46,399
for defeating replay attacks

188
00:08:46,800 --> 00:08:51,300
now

189
00:08:48,300 --> 00:08:53,519
the KDC or in this case specifically the

190
00:08:51,300 --> 00:08:55,560
ticket granting service does not yet

191
00:08:53,519 --> 00:08:58,260
have the session key but the ticket

192
00:08:55,560 --> 00:09:00,899
granting service uses the

193
00:08:58,260 --> 00:09:04,380
ticket which is also in the TGs request

194
00:09:00,899 --> 00:09:06,180
and is able to decrypt that using its

195
00:09:04,380 --> 00:09:09,300
long-term shared Secret

196
00:09:06,180 --> 00:09:11,839
and thereby pulling out the session key

197
00:09:09,300 --> 00:09:11,839
R-1

198
00:09:11,940 --> 00:09:17,820
and using that session key it can

199
00:09:14,040 --> 00:09:19,740
decrypt and verify the authenticator and

200
00:09:17,820 --> 00:09:22,019
ensure that the client information in

201
00:09:19,740 --> 00:09:24,899
the authenticator matches the client

202
00:09:22,019 --> 00:09:27,120
information in the TGs request

203
00:09:24,899 --> 00:09:29,339
if that all works and the client

204
00:09:27,120 --> 00:09:30,959
information lines up then it has

205
00:09:29,339 --> 00:09:33,420
authenticated the client and then the

206
00:09:30,959 --> 00:09:35,940
KDC according to whatever policy may

207
00:09:33,420 --> 00:09:38,100
exist in the organization can generate

208
00:09:35,940 --> 00:09:41,300
and send the TGs reply

209
00:09:38,100 --> 00:09:44,519
the TGs reply includes

210
00:09:41,300 --> 00:09:46,920
uh another session key

211
00:09:44,519 --> 00:09:50,519
so that's r-2 encrypted using the

212
00:09:46,920 --> 00:09:53,339
session key for the TGs session

213
00:09:50,519 --> 00:09:56,160
and it includes a ticket for the service

214
00:09:53,339 --> 00:09:58,560
so that's the lower part in yellow and

215
00:09:56,160 --> 00:09:59,660
that service ticket also includes the

216
00:09:58,560 --> 00:10:04,440
client information

217
00:09:59,660 --> 00:10:06,540
and an encrypted copy of the service

218
00:10:04,440 --> 00:10:09,300
session key

219
00:10:06,540 --> 00:10:12,180
processing the TGs reply

220
00:10:09,300 --> 00:10:15,839
the client will store the service ticket

221
00:10:12,180 --> 00:10:18,120
and a copy of the second session key the

222
00:10:15,839 --> 00:10:21,540
service session key

223
00:10:18,120 --> 00:10:23,700
so that's when a client wants to talk to

224
00:10:21,540 --> 00:10:25,380
a service that's the TGs request to get

225
00:10:23,700 --> 00:10:27,420
a ticket for that service

226
00:10:25,380 --> 00:10:29,700
the client has stored the ticket now the

227
00:10:27,420 --> 00:10:31,740
client can talk to the service in the

228
00:10:29,700 --> 00:10:34,380
application request it says hello server

229
00:10:31,740 --> 00:10:37,680
it includes the service ticket

230
00:10:34,380 --> 00:10:40,500
and it includes an authenticator and the

231
00:10:37,680 --> 00:10:41,940
processing that the server performs is

232
00:10:40,500 --> 00:10:43,560
similar to the processing that the

233
00:10:41,940 --> 00:10:45,779
ticket granting service just performed

234
00:10:43,560 --> 00:10:48,000
so it decrypts the ticket pulls out the

235
00:10:45,779 --> 00:10:49,800
session key uses the session key to

236
00:10:48,000 --> 00:10:52,140
decrypt and verify the authenticator

237
00:10:49,800 --> 00:10:53,700
checks the stock checks the timestamp

238
00:10:52,140 --> 00:10:56,640
checks that the client information

239
00:10:53,700 --> 00:10:58,980
matches up if all of that's good then it

240
00:10:56,640 --> 00:11:01,740
has authenticated the client

241
00:10:58,980 --> 00:11:04,440
and it can proceed to service the

242
00:11:01,740 --> 00:11:07,680
client's request and the session key can

243
00:11:04,440 --> 00:11:09,720
be used to establish a secure Channel

244
00:11:07,680 --> 00:11:11,339
and from that point on the client and

245
00:11:09,720 --> 00:11:14,540
the server can talk whatever protocol

246
00:11:11,339 --> 00:11:14,540
they want to talk

247
00:11:15,000 --> 00:11:19,380
okay

248
00:11:16,620 --> 00:11:21,540
I hope you all were able to stay with me

249
00:11:19,380 --> 00:11:23,579
for that it's a little bit to wrap your

250
00:11:21,540 --> 00:11:25,740
head around

251
00:11:23,579 --> 00:11:29,040
there are several extensions and

252
00:11:25,740 --> 00:11:31,320
Integrations for Kerberos so kerberus

253
00:11:29,040 --> 00:11:32,760
includes a pre-authentication framework

254
00:11:31,320 --> 00:11:36,000
which allows

255
00:11:32,760 --> 00:11:38,100
the client to integrate additional

256
00:11:36,000 --> 00:11:40,260
authentication mechanisms in the

257
00:11:38,100 --> 00:11:42,899
authentication Service request so these

258
00:11:40,260 --> 00:11:47,700
mechanisms can be used to for example

259
00:11:42,899 --> 00:11:50,600
include a one-time code like a totp in

260
00:11:47,700 --> 00:11:53,100
the authentication Exchange

261
00:11:50,600 --> 00:11:56,160
rather than just saying hey it's Bob and

262
00:11:53,100 --> 00:11:57,720
hoping that the authentication Service

263
00:11:56,160 --> 00:12:01,380
can

264
00:11:57,720 --> 00:12:03,420
respond with the encrypted

265
00:12:01,380 --> 00:12:05,820
session key in the ticket

266
00:12:03,420 --> 00:12:07,980
ticket granting ticket for Bob

267
00:12:05,820 --> 00:12:11,459
there are mechanisms for integrating

268
00:12:07,980 --> 00:12:14,820
Kerberos with GSS API and sasil

269
00:12:11,459 --> 00:12:16,920
as well as a mechanism for HTTP

270
00:12:14,820 --> 00:12:19,399
authentication using kerberus called SP

271
00:12:16,920 --> 00:12:19,399
nego

272
00:12:19,620 --> 00:12:24,959
there is an extension called

273
00:12:21,420 --> 00:12:28,019
authentication indicator which

274
00:12:24,959 --> 00:12:29,760
allows the ticket granting ticket and

275
00:12:28,019 --> 00:12:33,839
subsequent tickets so the service

276
00:12:29,760 --> 00:12:35,820
tickets issued using that TGT to carry

277
00:12:33,839 --> 00:12:38,040
along additional information about how

278
00:12:35,820 --> 00:12:40,160
the initial authentication was performed

279
00:12:38,040 --> 00:12:42,540
so for example

280
00:12:40,160 --> 00:12:46,740
the authentication indicator could

281
00:12:42,540 --> 00:12:49,820
indicate hey um he's this user Bob and

282
00:12:46,740 --> 00:12:52,940
Bob Bob's initial authentication

283
00:12:49,820 --> 00:12:57,480
included a tatp or a one-time password

284
00:12:52,940 --> 00:13:00,240
and the services in an organization can

285
00:12:57,480 --> 00:13:02,100
inspect the authentication indicator to

286
00:13:00,240 --> 00:13:02,820
make policy decisions so if you have a

287
00:13:02,100 --> 00:13:05,100
high

288
00:13:02,820 --> 00:13:06,380
uh high value service or a high

289
00:13:05,100 --> 00:13:08,519
Assurance service

290
00:13:06,380 --> 00:13:13,019
that you want

291
00:13:08,519 --> 00:13:15,300
users to have to use additional factors

292
00:13:13,019 --> 00:13:16,860
of authentication to access then you can

293
00:13:15,300 --> 00:13:19,139
carry that information along in the

294
00:13:16,860 --> 00:13:22,920
sequence of tickets so that the services

295
00:13:19,139 --> 00:13:25,920
can enforce those policies

296
00:13:22,920 --> 00:13:28,440
Kerberos also enables cross realm

297
00:13:25,920 --> 00:13:31,560
authentication so Realms can establish

298
00:13:28,440 --> 00:13:33,680
one-way or two-way trusts enabling

299
00:13:31,560 --> 00:13:36,899
principles in one realm to get tickets

300
00:13:33,680 --> 00:13:40,320
to access services in a different realm

301
00:13:36,899 --> 00:13:42,360
where this often arises is in large

302
00:13:40,320 --> 00:13:43,860
organizations with different departments

303
00:13:42,360 --> 00:13:46,260
or where you've had mergers and

304
00:13:43,860 --> 00:13:47,899
Acquisitions where two organizations

305
00:13:46,260 --> 00:13:51,779
with existing

306
00:13:47,899 --> 00:13:53,339
Kerberos deployments need to get the

307
00:13:51,779 --> 00:13:56,720
principles in those deployments to be

308
00:13:53,339 --> 00:13:56,720
able to talk to each other

309
00:13:57,839 --> 00:14:02,240
so the advantages of kerberus and

310
00:14:00,300 --> 00:14:04,800
certainly advantages over traditional

311
00:14:02,240 --> 00:14:08,040
password authentication

312
00:14:04,800 --> 00:14:09,540
so it's a single sign on system as

313
00:14:08,040 --> 00:14:12,540
you've seen that initial authentication

314
00:14:09,540 --> 00:14:14,639
gives you a TGT and that TGT can then be

315
00:14:12,540 --> 00:14:17,100
used to get tickets to access many

316
00:14:14,639 --> 00:14:20,160
different services for the duration of

317
00:14:17,100 --> 00:14:22,320
the validity of the TGT

318
00:14:20,160 --> 00:14:25,139
so this improves efficiency it reduces

319
00:14:22,320 --> 00:14:27,480
password fatigue it helps you eliminate

320
00:14:25,139 --> 00:14:31,860
identity silos in your organization

321
00:14:27,480 --> 00:14:34,320
which can become a risk

322
00:14:31,860 --> 00:14:36,839
the client has to expose their long-term

323
00:14:34,320 --> 00:14:40,740
secret only one time

324
00:14:36,839 --> 00:14:42,839
or one time per day or however long the

325
00:14:40,740 --> 00:14:45,720
TGT will last so that initial

326
00:14:42,839 --> 00:14:48,300
authentication is the only time where

327
00:14:45,720 --> 00:14:50,120
the user is typing their password or

328
00:14:48,300 --> 00:14:53,339
where the service

329
00:14:50,120 --> 00:14:56,459
principle is accessing its long-term

330
00:14:53,339 --> 00:14:58,980
secret to decrypt the

331
00:14:56,459 --> 00:15:01,380
um the TGT

332
00:14:58,980 --> 00:15:03,720
sorry to decrypt the session ticket for

333
00:15:01,380 --> 00:15:05,880
the ticket granting service session

334
00:15:03,720 --> 00:15:07,620
it's resistant to replay attacks because

335
00:15:05,880 --> 00:15:10,260
of the inclusion in the time of the time

336
00:15:07,620 --> 00:15:13,260
stamp in the messages in the protocol

337
00:15:10,260 --> 00:15:15,720
and Kerberos works well both for HTTP

338
00:15:13,260 --> 00:15:18,540
based protocols as well as bare Network

339
00:15:15,720 --> 00:15:21,839
protocols where other single sign-on

340
00:15:18,540 --> 00:15:24,660
protocols like saml or open ID connect

341
00:15:21,839 --> 00:15:28,260
do not work so well where you don't have

342
00:15:24,660 --> 00:15:29,160
a browser mediating the

343
00:15:28,260 --> 00:15:31,320
um

344
00:15:29,160 --> 00:15:33,480
The Carriage of the identity assertion

345
00:15:31,320 --> 00:15:34,820
between the identity provider and the

346
00:15:33,480 --> 00:15:39,480
service

347
00:15:34,820 --> 00:15:40,560
so for Bear protocols like ldap for

348
00:15:39,480 --> 00:15:42,560
example

349
00:15:40,560 --> 00:15:46,160
or SSH even

350
00:15:42,560 --> 00:15:46,160
Kerberos works very well

351
00:15:47,220 --> 00:15:53,399
but as we know passwords are not great

352
00:15:50,000 --> 00:15:56,399
they are not very human friendly

353
00:15:53,399 --> 00:15:58,740
and uh the password or key tab rotation

354
00:15:56,399 --> 00:16:01,260
to to try to improve the security and

355
00:15:58,740 --> 00:16:06,260
the resilience of your infrastructure

356
00:16:01,260 --> 00:16:06,260
can be administratively burdensome

357
00:16:06,660 --> 00:16:12,300
so this is where the PK unit protocol

358
00:16:08,820 --> 00:16:14,639
comes into its own so PK unit stands for

359
00:16:12,300 --> 00:16:18,480
public key cryptography

360
00:16:14,639 --> 00:16:21,440
for initial authentication in kerberus

361
00:16:18,480 --> 00:16:24,540
and with PK unit the client can use

362
00:16:21,440 --> 00:16:27,060
asymmetric cryptography in the

363
00:16:24,540 --> 00:16:30,120
authentication Service exchange to

364
00:16:27,060 --> 00:16:33,500
authenticate to the KDC

365
00:16:30,120 --> 00:16:36,959
the client presents an x509 certificate

366
00:16:33,500 --> 00:16:40,040
and signs a message which is included in

367
00:16:36,959 --> 00:16:42,800
the additional authentication

368
00:16:40,040 --> 00:16:46,620
part of the

369
00:16:42,800 --> 00:16:50,579
authentication Service request

370
00:16:46,620 --> 00:16:51,660
and the KDC in processing that as

371
00:16:50,579 --> 00:16:54,120
request

372
00:16:51,660 --> 00:16:56,459
can verify the certificate

373
00:16:54,120 --> 00:17:00,000
then verify the signature work out what

374
00:16:56,459 --> 00:17:04,140
is The Binding between the the key of

375
00:17:00,000 --> 00:17:07,319
the certificate and the principal

376
00:17:04,140 --> 00:17:10,140
which is attempting to authenticate

377
00:17:07,319 --> 00:17:13,260
and then if all of that checks out the

378
00:17:10,140 --> 00:17:14,520
KDC will encrypt its response not using

379
00:17:13,260 --> 00:17:16,860
the long term

380
00:17:14,520 --> 00:17:18,839
uh session or sorry the long term secret

381
00:17:16,860 --> 00:17:21,780
key of the client

382
00:17:18,839 --> 00:17:24,839
but rather using diffie-hellman or some

383
00:17:21,780 --> 00:17:26,760
analogous key agreement algorithm or

384
00:17:24,839 --> 00:17:29,299
some other public key encryption

385
00:17:26,760 --> 00:17:29,299
algorithm

386
00:17:31,080 --> 00:17:37,679
so visualizing the PK init

387
00:17:34,580 --> 00:17:40,919
authentication Service Exchange

388
00:17:37,679 --> 00:17:42,780
this time the as request has quite a bit

389
00:17:40,919 --> 00:17:45,179
more in it than just Halo it's me it's

390
00:17:42,780 --> 00:17:47,280
client can I please authenticate

391
00:17:45,179 --> 00:17:50,640
it includes

392
00:17:47,280 --> 00:17:54,000
this first upper box and Authenticator

393
00:17:50,640 --> 00:17:55,559
which includes the time stamp and if the

394
00:17:54,000 --> 00:17:58,919
client wants to use diffie-hellman key

395
00:17:55,559 --> 00:18:01,620
agreement to derive the

396
00:17:58,919 --> 00:18:04,380
shared secret for encrypting the reply

397
00:18:01,620 --> 00:18:06,480
then it will include a DH value that's

398
00:18:04,380 --> 00:18:09,960
not required in all cases but this is

399
00:18:06,480 --> 00:18:13,380
one of the more common variations of the

400
00:18:09,960 --> 00:18:17,940
PK unit authentication Exchange

401
00:18:13,380 --> 00:18:20,880
it also includes its x509 certificate

402
00:18:17,940 --> 00:18:23,520
uh so the x509 certificate contains a

403
00:18:20,880 --> 00:18:26,660
copy of the client's public key

404
00:18:23,520 --> 00:18:29,520
and various other attributes

405
00:18:26,660 --> 00:18:31,559
representing the client

406
00:18:29,520 --> 00:18:33,240
as well as information about the public

407
00:18:31,559 --> 00:18:34,400
key infrastructure who issued the

408
00:18:33,240 --> 00:18:39,799
certificate

409
00:18:34,400 --> 00:18:41,580
where can the ocsp responses be

410
00:18:39,799 --> 00:18:44,760
retrieved from

411
00:18:41,580 --> 00:18:47,520
or where is a crl so that the

412
00:18:44,760 --> 00:18:50,240
KDC could perform revocation checking

413
00:18:47,520 --> 00:18:50,240
and so on

414
00:18:51,480 --> 00:18:58,620
so the KDC validates the signature

415
00:18:56,160 --> 00:19:01,440
validates the certificate and the

416
00:18:58,620 --> 00:19:02,100
certificate chain up to a trusted

417
00:19:01,440 --> 00:19:04,860
um

418
00:19:02,100 --> 00:19:06,480
trust anchor or root certificate

419
00:19:04,860 --> 00:19:08,340
and

420
00:19:06,480 --> 00:19:11,820
checks The Binding between the public

421
00:19:08,340 --> 00:19:14,400
key and known principles or

422
00:19:11,820 --> 00:19:16,320
the principle that is purporting to be

423
00:19:14,400 --> 00:19:18,960
the one authenticating

424
00:19:16,320 --> 00:19:20,580
and if that all checks out then it can

425
00:19:18,960 --> 00:19:25,080
send a reply

426
00:19:20,580 --> 00:19:27,260
which similar to the as reply when using

427
00:19:25,080 --> 00:19:30,059
the standard shared secret

428
00:19:27,260 --> 00:19:31,980
authentication it includes a randomly

429
00:19:30,059 --> 00:19:34,860
generated session key

430
00:19:31,980 --> 00:19:37,559
uh encrypted using in this case the

431
00:19:34,860 --> 00:19:43,160
diffie-hellman value

432
00:19:37,559 --> 00:19:43,160
and it includes a ticket granting ticket

433
00:19:44,640 --> 00:19:51,120
as before the client will decrypt

434
00:19:47,820 --> 00:19:53,400
the session key the TGs session key and

435
00:19:51,120 --> 00:19:55,679
store the TGT

436
00:19:53,400 --> 00:19:59,640
from this point on the rest of the

437
00:19:55,679 --> 00:20:02,539
kerberus protocol is exactly the same as

438
00:19:59,640 --> 00:20:05,760
explained previously so there's no more

439
00:20:02,539 --> 00:20:08,220
use of the private key

440
00:20:05,760 --> 00:20:11,039
there's no more use of any long-term

441
00:20:08,220 --> 00:20:12,720
shared secret that's shared between the

442
00:20:11,039 --> 00:20:14,580
client and the KDC

443
00:20:12,720 --> 00:20:18,059
and everything uses symmetric

444
00:20:14,580 --> 00:20:20,880
cryptography from here on

445
00:20:18,059 --> 00:20:23,700
so what is the user experience of PK in

446
00:20:20,880 --> 00:20:25,080
it well if you're using a CLI if you're

447
00:20:23,700 --> 00:20:28,200
dealing with

448
00:20:25,080 --> 00:20:31,559
services that want to use PK in it to to

449
00:20:28,200 --> 00:20:34,980
grab a TGT then you can use the standard

450
00:20:31,559 --> 00:20:38,820
kerberus or MIT kerberus client tools

451
00:20:34,980 --> 00:20:40,799
the k-unit command and you just have to

452
00:20:38,820 --> 00:20:43,260
provide some additional arguments to

453
00:20:40,799 --> 00:20:45,419
explain while I'm using PK in it and you

454
00:20:43,260 --> 00:20:47,340
can find my cert over there and my key

455
00:20:45,419 --> 00:20:48,600
over here

456
00:20:47,340 --> 00:20:50,940
um and there are

457
00:20:48,600 --> 00:20:54,780
variations of this command if you want

458
00:20:50,940 --> 00:20:56,179
to use a key stored in a pkcs11 module

459
00:20:54,780 --> 00:21:01,260
for example

460
00:20:56,179 --> 00:21:04,500
for a smart card or an HSM

461
00:21:01,260 --> 00:21:07,559
and speaking of smart cards uh for a

462
00:21:04,500 --> 00:21:10,020
user experience someone who wants to sit

463
00:21:07,559 --> 00:21:12,240
down at a workstation and log in at the

464
00:21:10,020 --> 00:21:13,679
start of the day you could use Smart

465
00:21:12,240 --> 00:21:17,700
cards to do that

466
00:21:13,679 --> 00:21:20,700
and sssd and it can integrate with your

467
00:21:17,700 --> 00:21:23,940
Linux login managers like gdm it will

468
00:21:20,700 --> 00:21:26,039
prompt for a pin for the smart card if

469
00:21:23,940 --> 00:21:30,419
the slot requires a pin

470
00:21:26,039 --> 00:21:33,720
and during the workstation login it

471
00:21:30,419 --> 00:21:36,120
acquires the TGT so there's no further

472
00:21:33,720 --> 00:21:38,280
user interaction required besides that

473
00:21:36,120 --> 00:21:40,440
initial login

474
00:21:38,280 --> 00:21:42,960
you can also configure your system to

475
00:21:40,440 --> 00:21:45,000
log you out or lock the screen if the

476
00:21:42,960 --> 00:21:47,700
smart card is detached

477
00:21:45,000 --> 00:21:49,620
and I understand that the user

478
00:21:47,700 --> 00:21:52,440
experience for Windows if you're using

479
00:21:49,620 --> 00:21:55,940
PK unit in Windows environment is fairly

480
00:21:52,440 --> 00:21:55,940
similar to what I've just described

481
00:21:56,480 --> 00:22:03,120
to enable Smart Card login with sssd and

482
00:22:00,480 --> 00:22:05,700
these commands are Fedora and Rel

483
00:22:03,120 --> 00:22:07,200
specific but I imagine it will be

484
00:22:05,700 --> 00:22:09,059
something similar for other

485
00:22:07,200 --> 00:22:11,340
distributions

486
00:22:09,059 --> 00:22:13,799
you can simply use the auth select

487
00:22:11,340 --> 00:22:16,320
command to enable the with smart card

488
00:22:13,799 --> 00:22:18,840
feature and if you wish the with smart

489
00:22:16,320 --> 00:22:22,740
card lock-on removal feature

490
00:22:18,840 --> 00:22:25,640
and if you say with smart card required

491
00:22:22,740 --> 00:22:27,840
then that will require smart card login

492
00:22:25,640 --> 00:22:30,360
exclusively for that workstation so

493
00:22:27,840 --> 00:22:33,659
there'll be no option to fall back to

494
00:22:30,360 --> 00:22:35,700
password authentication so in some high

495
00:22:33,659 --> 00:22:37,220
security environments that might be

496
00:22:35,700 --> 00:22:41,460
desirable

497
00:22:37,220 --> 00:22:43,080
however if you leave your smart card at

498
00:22:41,460 --> 00:22:44,280
home for the day you're going to have a

499
00:22:43,080 --> 00:22:46,799
problem

500
00:22:44,280 --> 00:22:50,340
you also have to update the sssd

501
00:22:46,799 --> 00:22:53,059
configuration with a couple of options

502
00:22:50,340 --> 00:22:55,799
to enable the Pam

503
00:22:53,059 --> 00:22:59,419
the options for the Pam module to use

504
00:22:55,799 --> 00:22:59,419
certificate Authentication

505
00:23:01,320 --> 00:23:08,340
and with the free IPA provider

506
00:23:04,620 --> 00:23:08,340
for sssd

507
00:23:08,820 --> 00:23:13,919
you can

508
00:23:10,520 --> 00:23:16,679
by default use an exact certificate

509
00:23:13,919 --> 00:23:19,980
match only so this means that the

510
00:23:16,679 --> 00:23:22,620
principles the user or the hosts uh

511
00:23:19,980 --> 00:23:25,200
entry in the ldap database

512
00:23:22,620 --> 00:23:28,200
has to have a user certificate attribute

513
00:23:25,200 --> 00:23:29,280
containing the exact certificate being

514
00:23:28,200 --> 00:23:31,500
used

515
00:23:29,280 --> 00:23:33,960
so when the

516
00:23:31,500 --> 00:23:36,659
sssd

517
00:23:33,960 --> 00:23:38,159
and the KDC are processing the

518
00:23:36,659 --> 00:23:40,980
certificate

519
00:23:38,159 --> 00:23:45,020
it will use that exact certificate value

520
00:23:40,980 --> 00:23:45,020
in an ldap search to find the principle

521
00:23:45,299 --> 00:23:48,539
however this has some administrative

522
00:23:47,220 --> 00:23:51,120
overhead when you're dealing with

523
00:23:48,539 --> 00:23:54,059
renewals or revocations

524
00:23:51,120 --> 00:23:56,400
in that anytime that happens and a new

525
00:23:54,059 --> 00:23:58,620
certificate is issued an administrator

526
00:23:56,400 --> 00:24:01,980
has to go or an automated system has to

527
00:23:58,620 --> 00:24:04,260
go and update those entries the

528
00:24:01,980 --> 00:24:05,940
alternative is certificate mapping rules

529
00:24:04,260 --> 00:24:07,860
where we can use attributes in the

530
00:24:05,940 --> 00:24:11,100
certificate to look up the principle for

531
00:24:07,860 --> 00:24:12,600
example the user ID in the subject

532
00:24:11,100 --> 00:24:15,960
distinguished name

533
00:24:12,600 --> 00:24:20,220
or an email address or the subject DNS

534
00:24:15,960 --> 00:24:23,340
name to look up a host for example

535
00:24:20,220 --> 00:24:25,260
uh the caveat here is that at least in

536
00:24:23,340 --> 00:24:27,600
the versions that I have tested

537
00:24:25,260 --> 00:24:30,059
only one active mapping rule can be used

538
00:24:27,600 --> 00:24:31,980
which is somewhat Limited

539
00:24:30,059 --> 00:24:35,159
however it does avoid the administrative

540
00:24:31,980 --> 00:24:37,080
overhead of having to update the

541
00:24:35,159 --> 00:24:38,880
principles outlap entry every time a new

542
00:24:37,080 --> 00:24:40,799
certificate is being issued

543
00:24:38,880 --> 00:24:42,720
particularly if you have short-lived

544
00:24:40,799 --> 00:24:44,880
certificates it can be much more

545
00:24:42,720 --> 00:24:46,679
desirable to use certificate mapping

546
00:24:44,880 --> 00:24:48,840
rules

547
00:24:46,679 --> 00:24:52,320
and the client search can be signed by

548
00:24:48,840 --> 00:24:54,600
the free IPA internal CA or by any

549
00:24:52,320 --> 00:24:59,220
third-party CA you just have to add that

550
00:24:54,600 --> 00:25:01,740
third party CA as a trusted uh route or

551
00:24:59,220 --> 00:25:03,059
as a trust anchor doesn't have to be a

552
00:25:01,740 --> 00:25:04,620
root certificate sometimes we'll

553
00:25:03,059 --> 00:25:07,260
sometimes won't

554
00:25:04,620 --> 00:25:10,580
but you have to just explicitly add that

555
00:25:07,260 --> 00:25:10,580
CA as a trusted cert

556
00:25:10,860 --> 00:25:15,559
demo time

557
00:25:12,780 --> 00:25:15,559
okay

558
00:25:16,860 --> 00:25:24,059
so

559
00:25:19,200 --> 00:25:26,580
here is a workstation enrolled in

560
00:25:24,059 --> 00:25:30,059
a free IPA domain this is all running on

561
00:25:26,580 --> 00:25:31,799
a network of virtual machines on my

562
00:25:30,059 --> 00:25:35,520
laptop here

563
00:25:31,799 --> 00:25:37,559
so first of all their standard Kerberos

564
00:25:35,520 --> 00:25:40,320
login experience so I'm going to use

565
00:25:37,559 --> 00:25:42,799
password authentication logging in as

566
00:25:40,320 --> 00:25:42,799
Alice

567
00:25:45,059 --> 00:25:49,620
and so

568
00:25:47,460 --> 00:25:52,440
Alice is logged in

569
00:25:49,620 --> 00:25:54,000
whoa oh

570
00:25:52,440 --> 00:25:56,220
it's going to get a bit more exciting

571
00:25:54,000 --> 00:25:58,679
than that but uh just so that was using

572
00:25:56,220 --> 00:26:03,659
uh password authentication

573
00:25:58,679 --> 00:26:05,820
and uh if we run klist to list the

574
00:26:03,659 --> 00:26:07,860
um the tickets that I have in my session

575
00:26:05,820 --> 00:26:11,039
already

576
00:26:07,860 --> 00:26:15,140
I have uh the TGT so the TGT was

577
00:26:11,039 --> 00:26:15,140
acquired as part of their login

578
00:26:15,179 --> 00:26:19,559
what can I do with a TGT well for

579
00:26:17,279 --> 00:26:21,860
example I can hit any service that is

580
00:26:19,559 --> 00:26:24,960
using Kerberos Authentication

581
00:26:21,860 --> 00:26:30,900
I'll run an IPA command this is going to

582
00:26:24,960 --> 00:26:35,039
hit free ipas HTTP API so I might just

583
00:26:30,900 --> 00:26:36,840
say IPA I don't know user find Bob

584
00:26:35,039 --> 00:26:40,740
is there a user called Bob in this org

585
00:26:36,840 --> 00:26:43,860
ah what do you know there is and um

586
00:26:40,740 --> 00:26:45,600
if we now run klist again we'll see that

587
00:26:43,860 --> 00:26:49,860
in the background

588
00:26:45,600 --> 00:26:52,860
and without any uh prompting to the user

589
00:26:49,860 --> 00:26:55,980
a ticket was acquired for

590
00:26:52,860 --> 00:26:57,840
um well the HTTP service running on

591
00:26:55,980 --> 00:26:59,700
such and such a host which is one of the

592
00:26:57,840 --> 00:27:02,159
IPA servers

593
00:26:59,700 --> 00:27:04,380
uh I could also

594
00:27:02,159 --> 00:27:06,440
talk to ldap

595
00:27:04,380 --> 00:27:09,740
so why don't I do

596
00:27:06,440 --> 00:27:09,740
ldap search

597
00:27:10,320 --> 00:27:14,039
and

598
00:27:11,880 --> 00:27:15,900
then search for

599
00:27:14,039 --> 00:27:19,580
Bob again here

600
00:27:15,900 --> 00:27:19,580
let's find out what Bob's email is

601
00:27:20,580 --> 00:27:26,659
thank you very much William indeed it is

602
00:27:23,039 --> 00:27:29,580
okay unsurprisingly Bob's mail is Bob at

603
00:27:26,659 --> 00:27:31,380
ipa.test but again running k-list oh

604
00:27:29,580 --> 00:27:34,440
what happened in the background we got a

605
00:27:31,380 --> 00:27:37,080
ticket for the ldap service

606
00:27:34,440 --> 00:27:40,679
so that's demonstrating the single

607
00:27:37,080 --> 00:27:44,539
sign-on aspect of kerberus

608
00:27:40,679 --> 00:27:44,539
so I'm now going to log out

609
00:27:52,020 --> 00:27:55,820
and

610
00:27:53,820 --> 00:27:55,820
um

611
00:27:56,220 --> 00:27:59,659
I'm going to

612
00:28:00,419 --> 00:28:05,220
attach a Ubi key to the VM so I've got a

613
00:28:03,000 --> 00:28:06,840
UB key plugged into my laptop this

614
00:28:05,220 --> 00:28:09,539
command is just to do the USB

615
00:28:06,840 --> 00:28:11,460
passthrough so this is if you're using a

616
00:28:09,539 --> 00:28:13,140
workstation not in a VM you wouldn't

617
00:28:11,460 --> 00:28:17,179
have to do this

618
00:28:13,140 --> 00:28:17,179
and attaching the UB key

619
00:28:18,120 --> 00:28:23,580
haha not working

620
00:28:21,299 --> 00:28:25,580
so let me just detach that

621
00:28:23,580 --> 00:28:25,580
um

622
00:28:28,559 --> 00:28:31,580
and work out why

623
00:28:32,100 --> 00:28:34,640
hmm

624
00:28:40,559 --> 00:28:45,620
nope

625
00:28:42,900 --> 00:28:45,620
why not working

626
00:28:45,900 --> 00:28:49,140
okay

627
00:28:47,340 --> 00:28:50,279
let's try something else

628
00:28:49,140 --> 00:28:51,480
all right

629
00:28:50,279 --> 00:28:54,539
um

630
00:28:51,480 --> 00:28:57,059
so it was actually working but for some

631
00:28:54,539 --> 00:28:59,220
reason it wasn't detecting that a

632
00:28:57,059 --> 00:29:01,080
certificate for Alice was on the smart

633
00:28:59,220 --> 00:29:05,340
card and

634
00:29:01,080 --> 00:29:07,500
um moving me straight to uh to this

635
00:29:05,340 --> 00:29:09,240
prompt without any user interaction

636
00:29:07,500 --> 00:29:11,220
which is what I was expecting to happen

637
00:29:09,240 --> 00:29:12,419
didn't happen but the smart card is

638
00:29:11,220 --> 00:29:15,840
working

639
00:29:12,419 --> 00:29:18,679
so I'm going to put in the PIN

640
00:29:15,840 --> 00:29:18,679
and press enter

641
00:29:20,940 --> 00:29:24,860
okay so the login has succeeded

642
00:29:27,419 --> 00:29:32,960
and again if we

643
00:29:29,640 --> 00:29:32,960
take a list

644
00:29:34,080 --> 00:29:39,899
and we've got a TGT so this was using

645
00:29:36,720 --> 00:29:43,440
the PK init protocol to log into this

646
00:29:39,899 --> 00:29:45,360
workstation and we have our initial TGT

647
00:29:43,440 --> 00:29:47,940
and again

648
00:29:45,360 --> 00:29:52,440
you know IPA user find Bob this TGT

649
00:29:47,940 --> 00:29:55,200
acquired via PK unit is as good as a TGT

650
00:29:52,440 --> 00:29:57,299
acquired using password authentication

651
00:29:55,200 --> 00:29:59,399
in fact if you're using authentication

652
00:29:57,299 --> 00:30:01,559
indicators it might even be a bit better

653
00:29:59,399 --> 00:30:03,840
than such a ticket because it could

654
00:30:01,559 --> 00:30:06,840
potentially allow access to Services

655
00:30:03,840 --> 00:30:09,539
requiring a higher degree of assurance

656
00:30:06,840 --> 00:30:11,820
or additional factors for the initial

657
00:30:09,539 --> 00:30:14,520
Authentication

658
00:30:11,820 --> 00:30:15,899
okay

659
00:30:14,520 --> 00:30:17,279
so

660
00:30:15,899 --> 00:30:18,899
um I'm just going to leave that session

661
00:30:17,279 --> 00:30:22,380
as is for now

662
00:30:18,899 --> 00:30:24,240
and jump back to the slides

663
00:30:22,380 --> 00:30:26,159
so the advantages of PK unit well

664
00:30:24,240 --> 00:30:29,039
there's no more shared Secret

665
00:30:26,159 --> 00:30:32,580
the key can reside in a smart card as in

666
00:30:29,039 --> 00:30:36,299
the demo or in a TPM or secure Enclave

667
00:30:32,580 --> 00:30:38,279
in an HSM it could reside in a mobile

668
00:30:36,299 --> 00:30:41,100
phone secure enclave and you could use

669
00:30:38,279 --> 00:30:43,500
NFC if you have an NFC Reader on your

670
00:30:41,100 --> 00:30:45,840
workstation

671
00:30:43,500 --> 00:30:47,940
um the possibilities are really quite

672
00:30:45,840 --> 00:30:50,340
many and varied

673
00:30:47,940 --> 00:30:52,620
and the rest of the protocol after the

674
00:30:50,340 --> 00:30:55,380
authentication Service exchange is

675
00:30:52,620 --> 00:30:56,880
unchanged which means Services don't

676
00:30:55,380 --> 00:31:00,000
need to do anything

677
00:30:56,880 --> 00:31:02,039
and you still have the benefit of using

678
00:31:00,000 --> 00:31:04,700
a more secure means of the initial

679
00:31:02,039 --> 00:31:04,700
Authentication

680
00:31:05,940 --> 00:31:11,159
but of course there are some

681
00:31:07,380 --> 00:31:12,720
complexities so you need an x509 pki and

682
00:31:11,159 --> 00:31:16,320
that's no small thing

683
00:31:12,720 --> 00:31:19,200
and along with that comes the

684
00:31:16,320 --> 00:31:20,100
comes the renewal considerations

685
00:31:19,200 --> 00:31:24,659
um

686
00:31:20,100 --> 00:31:25,919
so certificates have expiry dates how

687
00:31:24,659 --> 00:31:28,200
long those certificates live really

688
00:31:25,919 --> 00:31:30,360
depends on on your organization's policy

689
00:31:28,200 --> 00:31:33,020
something like one year

690
00:31:30,360 --> 00:31:35,580
for a user certificate

691
00:31:33,020 --> 00:31:38,779
might be considered reasonable as a good

692
00:31:35,580 --> 00:31:42,320
balance between making sure that

693
00:31:38,779 --> 00:31:44,279
credentials don't live too long

694
00:31:42,320 --> 00:31:46,740
versus

695
00:31:44,279 --> 00:31:50,520
the burden of having to

696
00:31:46,740 --> 00:31:54,179
issue new certificates too frequently

697
00:31:50,520 --> 00:31:57,299
and revocation checking is hard to do

698
00:31:54,179 --> 00:31:58,980
right and it can be introducing

699
00:31:57,299 --> 00:32:01,860
additional latency into the protocol

700
00:31:58,980 --> 00:32:04,080
while for example the KDC goes off and

701
00:32:01,860 --> 00:32:06,179
talks to an ocsp server presenting the

702
00:32:04,080 --> 00:32:07,919
certificate or the certificate serial

703
00:32:06,179 --> 00:32:10,500
number and saying hey certificate

704
00:32:07,919 --> 00:32:11,720
Authority is this certificate still

705
00:32:10,500 --> 00:32:14,220
valid

706
00:32:11,720 --> 00:32:15,659
when you're dealing with users people

707
00:32:14,220 --> 00:32:18,240
who might be coming and leaving the

708
00:32:15,659 --> 00:32:20,520
company getting fired

709
00:32:18,240 --> 00:32:22,740
the revocation checking is really

710
00:32:20,520 --> 00:32:27,419
potentially an extremely critical part

711
00:32:22,740 --> 00:32:30,360
of the security posture of your pki in

712
00:32:27,419 --> 00:32:32,640
general and your PK init deployment or

713
00:32:30,360 --> 00:32:34,260
your Cobra deployment using PK units

714
00:32:32,640 --> 00:32:36,720
specifically

715
00:32:34,260 --> 00:32:39,179
if you want the additional security that

716
00:32:36,720 --> 00:32:41,179
comes with putting your certificates on

717
00:32:39,179 --> 00:32:43,460
Smart cards

718
00:32:41,179 --> 00:32:47,700
UV keys

719
00:32:43,460 --> 00:32:50,580
or for services into hsms or for the KDC

720
00:32:47,700 --> 00:32:52,620
into an HSM then you will have

721
00:32:50,580 --> 00:32:55,020
additional cost associated with the

722
00:32:52,620 --> 00:32:57,179
hardware the setup the administration of

723
00:32:55,020 --> 00:32:59,580
all of that but of course the

724
00:32:57,179 --> 00:33:03,840
acquisition cost is much higher

725
00:32:59,580 --> 00:33:06,480
and there is the thorny question of how

726
00:33:03,840 --> 00:33:09,120
to establish or verify The Binding

727
00:33:06,480 --> 00:33:12,179
between the public key and the principal

728
00:33:09,120 --> 00:33:15,299
the RFC says this and I'll just focus on

729
00:33:12,179 --> 00:33:18,179
this first sentence the KDC must capital

730
00:33:15,299 --> 00:33:20,220
m capital u capital S capital T also

731
00:33:18,179 --> 00:33:23,100
check that the client's public key used

732
00:33:20,220 --> 00:33:24,899
to verify the client's signature is

733
00:33:23,100 --> 00:33:28,260
bound to the client principal name

734
00:33:24,899 --> 00:33:30,240
specified in the as request

735
00:33:28,260 --> 00:33:34,200
note also client principal name

736
00:33:30,240 --> 00:33:36,960
specified in the as request so the

737
00:33:34,200 --> 00:33:40,380
principle that the client says it is

738
00:33:36,960 --> 00:33:43,080
is something supplied by the client hmm

739
00:33:40,380 --> 00:33:45,000
interesting okay so there are several

740
00:33:43,080 --> 00:33:46,679
ways to do this you can encode the

741
00:33:45,000 --> 00:33:50,399
principal name directly in the

742
00:33:46,679 --> 00:33:53,159
certificate using a krb5 principal name

743
00:33:50,399 --> 00:33:55,019
subject alternative name value in

744
00:33:53,159 --> 00:33:59,940
Microsoft environments there's also the

745
00:33:55,019 --> 00:34:02,760
UPN San name type

746
00:33:59,940 --> 00:34:04,740
you can associate the certificate or the

747
00:34:02,760 --> 00:34:06,080
key directly with the principle in the

748
00:34:04,740 --> 00:34:09,599
database

749
00:34:06,080 --> 00:34:12,119
this is the exact certificate matching

750
00:34:09,599 --> 00:34:14,040
that I described for free IPA as the

751
00:34:12,119 --> 00:34:16,020
default Behavior

752
00:34:14,040 --> 00:34:18,720
and uh yeah I mentioned the

753
00:34:16,020 --> 00:34:21,480
administrative overheads that arise in

754
00:34:18,720 --> 00:34:23,399
that scenario but it is quite secure

755
00:34:21,480 --> 00:34:25,619
and you can use other heuristics for

756
00:34:23,399 --> 00:34:28,139
example if the certificate has a DNS

757
00:34:25,619 --> 00:34:30,659
name subject alt name then we can look

758
00:34:28,139 --> 00:34:34,040
for a host principle with that name if

759
00:34:30,659 --> 00:34:37,139
it has an RFC 822 name an email address

760
00:34:34,040 --> 00:34:39,540
then maybe we look for the user with

761
00:34:37,139 --> 00:34:41,520
that email address in the database but

762
00:34:39,540 --> 00:34:43,260
the long and the short of it is you'd

763
00:34:41,520 --> 00:34:46,020
better not mess this up either in the

764
00:34:43,260 --> 00:34:52,379
policy or in the implementation

765
00:34:46,020 --> 00:34:56,599
oh hmm okay so cve 2022 4254 uh demo

766
00:34:52,379 --> 00:34:56,599
time let me not get ahead of myself so

767
00:34:59,640 --> 00:35:03,900
um

768
00:35:01,619 --> 00:35:06,359
let me just change into this ominously

769
00:35:03,900 --> 00:35:08,480
named directory

770
00:35:06,359 --> 00:35:08,480
um

771
00:35:08,760 --> 00:35:12,480
let me do an IPA

772
00:35:11,099 --> 00:35:15,119
um

773
00:35:12,480 --> 00:35:16,740
user find Alice so by the way I'm Alice

774
00:35:15,119 --> 00:35:20,180
right now okay

775
00:35:16,740 --> 00:35:20,180
Alice at ipa.test

776
00:35:21,660 --> 00:35:28,980
um hands up how many people work in an

777
00:35:23,820 --> 00:35:33,180
organization where you can request your

778
00:35:28,980 --> 00:35:36,180
own email address or your own mail alias

779
00:35:33,180 --> 00:35:38,280
so a few hands up like maybe a quarter

780
00:35:36,180 --> 00:35:41,520
of the room so this is reasonably common

781
00:35:38,280 --> 00:35:45,000
and even more common in kind of I.T or

782
00:35:41,520 --> 00:35:47,520
technology focused organizations

783
00:35:45,000 --> 00:35:50,520
um that a user can say hey I would like

784
00:35:47,520 --> 00:35:52,260
such and such to be my email address

785
00:35:50,520 --> 00:35:55,140
um maybe you even have an automated

786
00:35:52,260 --> 00:35:55,800
system for doing that

787
00:35:55,140 --> 00:35:58,560
um

788
00:35:55,800 --> 00:36:01,980
Alice's organization has such a system

789
00:35:58,560 --> 00:36:03,060
and uh this system just checks the

790
00:36:01,980 --> 00:36:05,460
uniqueness

791
00:36:03,060 --> 00:36:08,540
of the

792
00:36:05,460 --> 00:36:11,339
of the email address and also that it is

793
00:36:08,540 --> 00:36:15,300
a syntactically valid

794
00:36:11,339 --> 00:36:17,820
email address according to RFC 822 or

795
00:36:15,300 --> 00:36:19,440
its successes

796
00:36:17,820 --> 00:36:23,180
so

797
00:36:19,440 --> 00:36:23,180
here's Alice's email alias

798
00:36:27,119 --> 00:36:33,240
and uh then Alice

799
00:36:30,020 --> 00:36:35,520
requested a certificate

800
00:36:33,240 --> 00:36:38,300
and the CSR

801
00:36:35,520 --> 00:36:38,300
uh

802
00:36:42,660 --> 00:36:48,420
um the CSR

803
00:36:44,339 --> 00:36:50,460
uh has common name Alice okay yep that

804
00:36:48,420 --> 00:36:53,520
that all seems very reasonable

805
00:36:50,460 --> 00:36:55,680
oh but also an rfca22 name with that

806
00:36:53,520 --> 00:36:57,680
email address

807
00:36:55,680 --> 00:36:57,680
um

808
00:37:03,660 --> 00:37:10,440
and the certificate that the ca issued

809
00:37:08,160 --> 00:37:12,660
um helpfully

810
00:37:10,440 --> 00:37:15,900
propagated that email address

811
00:37:12,660 --> 00:37:18,660
uh to the final certificate checking of

812
00:37:15,900 --> 00:37:21,839
course that that was in fact one of

813
00:37:18,660 --> 00:37:23,579
Alice's email addresses as recorded in

814
00:37:21,839 --> 00:37:25,260
Alice's ldap entry

815
00:37:23,579 --> 00:37:27,560
so what can we do now with this

816
00:37:25,260 --> 00:37:29,339
certificate hmm

817
00:37:27,560 --> 00:37:33,420
let's see

818
00:37:29,339 --> 00:37:35,820
um why don't we do a K in it Dash X

819
00:37:33,420 --> 00:37:38,460
509

820
00:37:35,820 --> 00:37:41,839
user identity

821
00:37:38,460 --> 00:37:41,839
equals file

822
00:37:42,359 --> 00:37:49,700
naughty.com and the corresponding key

823
00:37:46,560 --> 00:37:49,700
naughty dot key

824
00:37:49,980 --> 00:37:57,900
ah oh hang on a minute

825
00:37:52,680 --> 00:37:57,900
and uh I want to be admin laughs

826
00:37:59,040 --> 00:38:06,720
and oh I got a TGT

827
00:38:03,599 --> 00:38:10,460
for the guard user so this is

828
00:38:06,720 --> 00:38:10,460
um a complete domain takeover attack

829
00:38:10,560 --> 00:38:15,619
um so

830
00:38:12,900 --> 00:38:15,619
what just happened

831
00:38:15,720 --> 00:38:20,339
uh it's an ldap filter injection attack

832
00:38:17,820 --> 00:38:22,560
as you might have gathered

833
00:38:20,339 --> 00:38:25,859
by the presence of the suspicious

834
00:38:22,560 --> 00:38:29,339
characters in The syntactically valid uh

835
00:38:25,859 --> 00:38:32,400
RFC 822 name or email address

836
00:38:29,339 --> 00:38:34,800
free IPA is not vulnerable to this in

837
00:38:32,400 --> 00:38:36,780
its default configuration because in the

838
00:38:34,800 --> 00:38:40,520
default configuration only exact

839
00:38:36,780 --> 00:38:44,040
certificate matches enabled by default

840
00:38:40,520 --> 00:38:46,760
but if you do use cert map rules

841
00:38:44,040 --> 00:38:49,500
and if your cert map rule

842
00:38:46,760 --> 00:38:52,520
is constructed in such a way

843
00:38:49,500 --> 00:38:54,540
that might enable some

844
00:38:52,520 --> 00:38:57,720
misinterpretation of the structure of

845
00:38:54,540 --> 00:39:01,500
that filter based on the unescaped

846
00:38:57,720 --> 00:39:04,320
special characters in The RFC 822 name

847
00:39:01,500 --> 00:39:07,619
then you've got a big big problem

848
00:39:04,320 --> 00:39:11,339
when I discovered this it was

849
00:39:07,619 --> 00:39:15,300
only present in older versions of sssd

850
00:39:11,339 --> 00:39:17,820
it had already inadvertently been fixed

851
00:39:15,300 --> 00:39:20,220
um as it had been recognized as a bug

852
00:39:17,820 --> 00:39:23,339
but the security implications of that

853
00:39:20,220 --> 00:39:26,339
bug were not recognized at that time

854
00:39:23,339 --> 00:39:28,380
so there's a range of sssd versions that

855
00:39:26,339 --> 00:39:32,240
were vulnerable

856
00:39:28,380 --> 00:39:32,240
and they have now been fixed

857
00:39:34,440 --> 00:39:42,180
um you can also

858
00:39:38,420 --> 00:39:45,839
attack it in other ways for example if

859
00:39:42,180 --> 00:39:48,720
you have a certificate with a DNS name a

860
00:39:45,839 --> 00:39:52,140
wildcard DNS name that unescaped wild

861
00:39:48,720 --> 00:39:55,079
wild card means something else in ldap

862
00:39:52,140 --> 00:39:59,280
it's a substring match

863
00:39:55,079 --> 00:40:00,960
so if you had a certificate

864
00:39:59,280 --> 00:40:04,700
I don't know for a web host in your

865
00:40:00,960 --> 00:40:07,740
organization who's Sandy and S name was

866
00:40:04,700 --> 00:40:10,800
star.ipa.test then using that

867
00:40:07,740 --> 00:40:12,720
certificate you could get a TGT for any

868
00:40:10,800 --> 00:40:14,720
other host in the organization whose

869
00:40:12,720 --> 00:40:18,060
host name is

870
00:40:14,720 --> 00:40:21,000
something.ipa.test including your IPA

871
00:40:18,060 --> 00:40:22,760
servers if they happen to have a

872
00:40:21,000 --> 00:40:24,780
matching host name so

873
00:40:22,760 --> 00:40:26,839
this is

874
00:40:24,780 --> 00:40:30,000
perhaps a bit more

875
00:40:26,839 --> 00:40:34,020
plausible or likely to be

876
00:40:30,000 --> 00:40:36,599
out there in the real world than the um

877
00:40:34,020 --> 00:40:39,240
than the email address related attack

878
00:40:36,599 --> 00:40:41,940
that I demonstrated I've talked about

879
00:40:39,240 --> 00:40:45,480
the email address attack that will only

880
00:40:41,940 --> 00:40:49,920
work if your cert map rule has an or

881
00:40:45,480 --> 00:40:52,020
Clause because all of the um

882
00:40:49,920 --> 00:40:56,460
all of the Clauses in an and clause or

883
00:40:52,020 --> 00:40:58,680
if it's only a single filter expression

884
00:40:56,460 --> 00:41:00,599
would have to be matched but in an all

885
00:40:58,680 --> 00:41:01,740
Clause only one can be matched so it

886
00:41:00,599 --> 00:41:03,780
gives the attacker a bit more

887
00:41:01,740 --> 00:41:06,660
flexibility in kind of what sort of

888
00:41:03,780 --> 00:41:09,660
content they can try and inject into the

889
00:41:06,660 --> 00:41:11,400
ldap filter and still mount a successful

890
00:41:09,660 --> 00:41:13,619
attack

891
00:41:11,400 --> 00:41:16,680
um so in the email address attack this

892
00:41:13,619 --> 00:41:17,880
is what the final filter ends up looking

893
00:41:16,680 --> 00:41:20,820
like

894
00:41:17,880 --> 00:41:23,220
so we see this all expression and you

895
00:41:20,820 --> 00:41:26,700
know mail equals bogus uid equals admin

896
00:41:23,220 --> 00:41:28,800
CN equals such and such and so that

897
00:41:26,700 --> 00:41:30,900
single matching uid equals admin Clause

898
00:41:28,800 --> 00:41:32,599
is

899
00:41:30,900 --> 00:41:35,579
what caused the

900
00:41:32,599 --> 00:41:38,579
domain to get owned

901
00:41:35,579 --> 00:41:41,520
so the mitigations of course upgrade to

902
00:41:38,579 --> 00:41:43,740
the patched releases and list rules are

903
00:41:41,520 --> 00:41:45,599
harder harder to exploit than the all

904
00:41:43,740 --> 00:41:47,400
list rules so you may be able to change

905
00:41:45,599 --> 00:41:50,640
the structure of the rules

906
00:41:47,400 --> 00:41:53,160
you should certainly audit what data

907
00:41:50,640 --> 00:41:56,480
gets included in certs and how

908
00:41:53,160 --> 00:41:59,400
and exact certificate matching

909
00:41:56,480 --> 00:42:03,060
albeit with its administrative overheads

910
00:41:59,400 --> 00:42:05,240
is uh not vulnerable at all to this

911
00:42:03,060 --> 00:42:05,240
attack

912
00:42:05,700 --> 00:42:09,960
so security considerations properly

913
00:42:07,800 --> 00:42:12,420
Escape or sanitized all of your inputs

914
00:42:09,960 --> 00:42:14,640
all of the time that's just a general

915
00:42:12,420 --> 00:42:17,640
rule in all of Technology

916
00:42:14,640 --> 00:42:20,400
review your ca trust the certificate

917
00:42:17,640 --> 00:42:24,180
profiles and the validation Behavior

918
00:42:20,400 --> 00:42:26,040
and just because of value is valid like

919
00:42:24,180 --> 00:42:27,960
that email address does not mean that it

920
00:42:26,040 --> 00:42:29,820
is benign

921
00:42:27,960 --> 00:42:32,099
in summary the key in principle binding

922
00:42:29,820 --> 00:42:34,980
is a critical aspect of PK in its

923
00:42:32,099 --> 00:42:37,800
security it is as critical as validating

924
00:42:34,980 --> 00:42:41,220
the signature in the as request and

925
00:42:37,800 --> 00:42:43,760
validating the certification path up to

926
00:42:41,220 --> 00:42:47,400
a trusted CA

927
00:42:43,760 --> 00:42:50,220
uh some resources uh there's a write-up

928
00:42:47,400 --> 00:42:53,400
of the vulnerability on my blog at that

929
00:42:50,220 --> 00:42:56,640
is good link and also the official entry

930
00:42:53,400 --> 00:42:59,280
in the cve database and just a shout out

931
00:42:56,640 --> 00:43:03,780
to a related method uh sorry a related

932
00:42:59,280 --> 00:43:06,960
effort of introducing 502 and web authon

933
00:43:03,780 --> 00:43:09,060
support to free IPA and kerberus which

934
00:43:06,960 --> 00:43:12,119
is where you'll be able to use web

935
00:43:09,060 --> 00:43:15,839
authen Hardware tokens to perform that

936
00:43:12,119 --> 00:43:19,740
initial authentication this

937
00:43:15,839 --> 00:43:23,400
doesn't have the expiry and revocation

938
00:43:19,740 --> 00:43:24,660
capabilities that PK init does but it

939
00:43:23,400 --> 00:43:26,220
might be a good option in the future

940
00:43:24,660 --> 00:43:29,400
once this is delivered for some

941
00:43:26,220 --> 00:43:31,800
organizations as an alternative to PK in

942
00:43:29,400 --> 00:43:32,880
it to get more Security in your kerberus

943
00:43:31,800 --> 00:43:34,859
deployment

944
00:43:32,880 --> 00:43:37,450
that's the end hopefully there's time

945
00:43:34,859 --> 00:43:44,339
for one or two questions

946
00:43:37,450 --> 00:43:47,160
[Applause]

947
00:43:44,339 --> 00:43:49,560
thank you very much Fraser our actual

948
00:43:47,160 --> 00:43:51,119
official time is up but I'm we're coming

949
00:43:49,560 --> 00:43:54,619
on to lunchtime so I think we can

950
00:43:51,119 --> 00:43:54,619
probably manage one or two questions

951
00:43:55,560 --> 00:44:01,020
of course I have a question uh it's

952
00:43:58,619 --> 00:44:03,420
actually a little bit tangential but

953
00:44:01,020 --> 00:44:06,000
when you did the prv authentication with

954
00:44:03,420 --> 00:44:07,619
the pass through ubiki did you actually

955
00:44:06,000 --> 00:44:09,119
need to do the interaction with the

956
00:44:07,619 --> 00:44:11,760
device for that signature to be released

957
00:44:09,119 --> 00:44:13,800
or does it not require the interaction

958
00:44:11,760 --> 00:44:15,060
where you touch it

959
00:44:13,800 --> 00:44:17,339
uh

960
00:44:15,060 --> 00:44:19,880
no it in this case it does not require

961
00:44:17,339 --> 00:44:22,980
the interaction because this UB key has

962
00:44:19,880 --> 00:44:24,839
specifically been put into PIV mode so

963
00:44:22,980 --> 00:44:27,599
ubiques have different modes it's got a

964
00:44:24,839 --> 00:44:30,260
like a u2f or a Web author mode it has a

965
00:44:27,599 --> 00:44:33,780
PIV mode that brings me to bonus slide

966
00:44:30,260 --> 00:44:36,480
what is PIV uh PIV is a smart card

967
00:44:33,780 --> 00:44:38,339
standard from nist and there's also some

968
00:44:36,480 --> 00:44:42,319
mention there of some other related

969
00:44:38,339 --> 00:44:42,319
smart cards concerning the hardware

970
00:44:48,060 --> 00:44:54,599
you mentioned issues with crls and

971
00:44:51,200 --> 00:44:56,099
latency of the logins Etc

972
00:44:54,599 --> 00:44:59,220
um

973
00:44:56,099 --> 00:45:03,900
what do you see is the problem with just

974
00:44:59,220 --> 00:45:07,260
disabling users on the server versus

975
00:45:03,900 --> 00:45:09,240
versus worrying about crls

976
00:45:07,260 --> 00:45:12,180
right thank you for the question

977
00:45:09,240 --> 00:45:14,040
um it really depends on how the binding

978
00:45:12,180 --> 00:45:16,020
is done it's a matter of the kdc's

979
00:45:14,040 --> 00:45:19,440
implementation and policy

980
00:45:16,020 --> 00:45:24,180
so if you have for example certificates

981
00:45:19,440 --> 00:45:27,900
with the principal encoded in them

982
00:45:24,180 --> 00:45:31,020
uh in the krb5 principle name subject

983
00:45:27,900 --> 00:45:33,060
alt name field then a KDC doesn't

984
00:45:31,020 --> 00:45:35,099
necessarily have to go looking up that

985
00:45:33,060 --> 00:45:38,099
user in an ldap database

986
00:45:35,099 --> 00:45:40,920
in any case the ldap database

987
00:45:38,099 --> 00:45:43,380
would typically be local to the KDC

988
00:45:40,920 --> 00:45:48,180
certainly in free IPA it always is so

989
00:45:43,380 --> 00:45:51,359
that every IPA server in a topology has

990
00:45:48,180 --> 00:45:53,579
a KDC instance and an ldap instance and

991
00:45:51,359 --> 00:45:56,099
they they talk just over a local socket

992
00:45:53,579 --> 00:45:59,119
so talking to the ldap server is fast

993
00:45:56,099 --> 00:46:02,480
potentially a lot faster than

994
00:45:59,119 --> 00:46:06,420
talking to the

995
00:46:02,480 --> 00:46:07,319
ocsp server but yeah in this case

996
00:46:06,420 --> 00:46:08,880
um

997
00:46:07,319 --> 00:46:11,819
I'm not sure what happens in the free

998
00:46:08,880 --> 00:46:13,500
IPA implementation but it could check

999
00:46:11,819 --> 00:46:15,119
whether the user has been disabled there

1000
00:46:13,500 --> 00:46:19,079
or not

1001
00:46:15,119 --> 00:46:22,140
there exists many ways to configure and

1002
00:46:19,079 --> 00:46:23,940
deploy MIT Kerberos and whatever other

1003
00:46:22,140 --> 00:46:25,859
implementations out there I'm not sure

1004
00:46:23,940 --> 00:46:28,319
what they do but if the principles

1005
00:46:25,859 --> 00:46:31,680
encoded in the cert the KDC could use it

1006
00:46:28,319 --> 00:46:33,839
as is subject to revocation checking in

1007
00:46:31,680 --> 00:46:35,579
that case the latency of the revocation

1008
00:46:33,839 --> 00:46:39,240
check

1009
00:46:35,579 --> 00:46:44,160
um or the in the case of ocsp which is

1010
00:46:39,240 --> 00:46:44,160
an online revocation check versus

1011
00:46:44,280 --> 00:46:47,460
um

1012
00:46:44,880 --> 00:46:53,180
not doing any revocation checking could

1013
00:46:47,460 --> 00:46:56,040
in a large deployment be a factor

1014
00:46:53,180 --> 00:46:59,040
impairing the the usefulness or the user

1015
00:46:56,040 --> 00:47:02,040
experience of using PK unit

1016
00:46:59,040 --> 00:47:03,960
there is an extension for

1017
00:47:02,040 --> 00:47:07,560
clients to

1018
00:47:03,960 --> 00:47:09,619
include an ocsp response

1019
00:47:07,560 --> 00:47:13,560
in the

1020
00:47:09,619 --> 00:47:16,200
as request so you would call that ocsp

1021
00:47:13,560 --> 00:47:18,420
stapling if you're familiar with that in

1022
00:47:16,200 --> 00:47:20,520
a web context

1023
00:47:18,420 --> 00:47:24,240
the standards exist for doing the same

1024
00:47:20,520 --> 00:47:26,040
thing in PK init but I don't know how

1025
00:47:24,240 --> 00:47:30,119
widely implemented they are I certainly

1026
00:47:26,040 --> 00:47:33,500
don't know how to do it on

1027
00:47:30,119 --> 00:47:33,500
on the systems that I use

1028
00:47:34,140 --> 00:47:37,400
well thank you very much again

1029
00:47:38,760 --> 00:47:42,900
afraid we don't have time to take any

1030
00:47:40,619 --> 00:47:45,119
more questions if you have questions uh

1031
00:47:42,900 --> 00:47:46,800
come talk to me I'll answer them now to

1032
00:47:45,119 --> 00:47:49,579
the best of my ability

1033
00:47:46,800 --> 00:47:49,579
thank you

1034
00:47:49,720 --> 00:47:53,090
[Applause]