foreign
[Music]
good morning and our next talk is from
Fraser tweedale and he'll be talking on
Kerberos PK in it what why and how to
break it Fraser works on identity
management and PKR Solutions at Red Hat
they are passionate about functional
programming and security and enjoys
playing with those little plastic bricks
from Denmark today's talk by Fraser will
focus on PK in it a Kerberos extension
that replaces password authentication
and x509 certificates please welcome
Fraser
thank you
good morning
thank you for coming to my talk
so we're going to look at the Kerberos
Authentication Protocol a brief overview
of how that protocol works
then
we will look at the PK init protocol
extension
an overview of how that works and some
demos
I will discuss PK init security
considerations and I will demonstrate a
vulnerability in free ipas
implementation of PK init which I
discovered late last year and which has
now been fixed
so Kerberos is an Authentication
Protocol based on symmetric cryptography
it's a single sign-on protocol which
means that you can authenticate once
and you have a session for a
configurable duration for example one
day and using that
token from the initial authentication
you'll be able to also authenticate to
the various services or hosts that you
may need to access
Kerberos is typically deployed in
Enterprise environments so the idea is
coming at the start of the day log in
once and you no longer need to log in
throughout the day reducing password
fatigue eliminating silos of passwords
or identities across the business
applications in the organization
Kerberos emerged from MIT in the late
1980s the current version of the
protocol modulo the various extensions
which had been defined but the core
protocol version 5 is the main one in
use today that one was defined in 1993.
and the most recent RFC
defining the core protocol is RFC 4120
which was published in 2005.
the major implementations of kerberus
are MIT kerberus this was the original
and is still one of the most prevalent
or widely deployed Kerberos
implementations Microsoft active
directory of course is very widely
deployed and used in many many
organizations it also uses Kerberos
Heimdall is an alternative free software
implementation it's used in the bsds and
elsewhere
and free IPA or identity management in
Rel is a centralized identity management
solution that I have worked on at Red
Hat
and it includes MIT Kerberos with some
additional extensions
so the parties in the Kerberos protocol
are the client who wants to authenticate
two services
the key distribution center
which is a single service
containing a record of all of the
identities or principles
that have been defined in that Realm
and the services
that the clients may wish to
authenticate to
services are also principles so KDC is
the key distribution center it contains
two conceptually distinct Services the
authentication Service and the ticket
granting service these could actually be
separate hosts or separate distinct
programs but typically they are
provided together as part of a single
service which we call the KDC
the users the services and the KDC
itself are represented as principles in
an authentication Realm
so if you as a user
want to log in you can be you know Bob
or Bob Smith at
bobswidgets.com so the round part would
be bobswidgets.com
each principle has a long-term secret
key
which is known
to the the principal uh the user or a
host
and the KDC also has a copy of this key
so users typically derive their key from
a password using a password-based key
derivation algorithm
and hosts or Services typically stored
in a file
containing lists one or more of these
secret keys and those files are usually
called a key tab or a key table
the result of an Authentication
is called a ticket and the client
program on the user's behalf or on the
principal's behalf will keep a record of
that ticket for the validity duration of
that ticket
depending on the KDC configuration
tickets can also be renewed without an
additional authentication exchange but
that is a matter of policy
so uh trying to represent how Kurt Ross
Works in diagram form here are the three
parties client server and KDC
the client has a copy of its key
or
knows a secret from which it can derive
that same key
the server also has its key the KDC has
its own key a key for the ticket
granting Service as well as the keys for
all of the principles in the realm
so the initial authentication is between
the client and the KDC that's called the
authentication Service exchange and in
the authentication Service or as request
the client says to the KDC hey it's me
client it's me Bob or whoever
and there's actually no
authentication
proof carried in this message the client
just says it's me and the KDC sends a
reply
which contains a session key so that's
R-1 which is randomly generated
encrypted to the client's shared secret
and it contains what we call a ticket
granting ticket
which also contains a copy of that
session key as well as some client
information and that is encrypted to the
shared secret of the ticket granting
service
so after processing the authentication
Service
response or as rep
the client decrypts the session key if
that fails then
you know it can't if it can't decrypt it
then it wasn't Bob or it wasn't the user
that the client said it was
so that's where the proof of identity
comes even though there's no proof of
identity in the request itself
and it stores the TGT for later use
now when the client wants to talk to a
server or a service
it sends a TGs ticket granting service
request
and it says hello I would like to talk
to such and such a service
and it includes in its request the
ticket granting ticket which it had
previously stored
as well as an authenticator encrypted
with the session key
which includes some client information
and a timestamp
for defeating replay attacks
now
the KDC or in this case specifically the
ticket granting service does not yet
have the session key but the ticket
granting service uses the
ticket which is also in the TGs request
and is able to decrypt that using its
long-term shared Secret
and thereby pulling out the session key
R-1
and using that session key it can
decrypt and verify the authenticator and
ensure that the client information in
the authenticator matches the client
information in the TGs request
if that all works and the client
information lines up then it has
authenticated the client and then the
KDC according to whatever policy may
exist in the organization can generate
and send the TGs reply
the TGs reply includes
uh another session key
so that's r-2 encrypted using the
session key for the TGs session
and it includes a ticket for the service
so that's the lower part in yellow and
that service ticket also includes the
client information
and an encrypted copy of the service
session key
processing the TGs reply
the client will store the service ticket
and a copy of the second session key the
service session key
so that's when a client wants to talk to
a service that's the TGs request to get
a ticket for that service
the client has stored the ticket now the
client can talk to the service in the
application request it says hello server
it includes the service ticket
and it includes an authenticator and the
processing that the server performs is
similar to the processing that the
ticket granting service just performed
so it decrypts the ticket pulls out the
session key uses the session key to
decrypt and verify the authenticator
checks the stock checks the timestamp
checks that the client information
matches up if all of that's good then it
has authenticated the client
and it can proceed to service the
client's request and the session key can
be used to establish a secure Channel
and from that point on the client and
the server can talk whatever protocol
they want to talk
okay
I hope you all were able to stay with me
for that it's a little bit to wrap your
head around
there are several extensions and
Integrations for Kerberos so kerberus
includes a pre-authentication framework
which allows
the client to integrate additional
authentication mechanisms in the
authentication Service request so these
mechanisms can be used to for example
include a one-time code like a totp in
the authentication Exchange
rather than just saying hey it's Bob and
hoping that the authentication Service
can
respond with the encrypted
session key in the ticket
ticket granting ticket for Bob
there are mechanisms for integrating
Kerberos with GSS API and sasil
as well as a mechanism for HTTP
authentication using kerberus called SP
nego
there is an extension called
authentication indicator which
allows the ticket granting ticket and
subsequent tickets so the service
tickets issued using that TGT to carry
along additional information about how
the initial authentication was performed
so for example
the authentication indicator could
indicate hey um he's this user Bob and
Bob Bob's initial authentication
included a tatp or a one-time password
and the services in an organization can
inspect the authentication indicator to
make policy decisions so if you have a
high
uh high value service or a high
Assurance service
that you want
users to have to use additional factors
of authentication to access then you can
carry that information along in the
sequence of tickets so that the services
can enforce those policies
Kerberos also enables cross realm
authentication so Realms can establish
one-way or two-way trusts enabling
principles in one realm to get tickets
to access services in a different realm
where this often arises is in large
organizations with different departments
or where you've had mergers and
Acquisitions where two organizations
with existing
Kerberos deployments need to get the
principles in those deployments to be
able to talk to each other
so the advantages of kerberus and
certainly advantages over traditional
password authentication
so it's a single sign on system as
you've seen that initial authentication
gives you a TGT and that TGT can then be
used to get tickets to access many
different services for the duration of
the validity of the TGT
so this improves efficiency it reduces
password fatigue it helps you eliminate
identity silos in your organization
which can become a risk
the client has to expose their long-term
secret only one time
or one time per day or however long the
TGT will last so that initial
authentication is the only time where
the user is typing their password or
where the service
principle is accessing its long-term
secret to decrypt the
um the TGT
sorry to decrypt the session ticket for
the ticket granting service session
it's resistant to replay attacks because
of the inclusion in the time of the time
stamp in the messages in the protocol
and Kerberos works well both for HTTP
based protocols as well as bare Network
protocols where other single sign-on
protocols like saml or open ID connect
do not work so well where you don't have
a browser mediating the
um
The Carriage of the identity assertion
between the identity provider and the
service
so for Bear protocols like ldap for
example
or SSH even
Kerberos works very well
but as we know passwords are not great
they are not very human friendly
and uh the password or key tab rotation
to to try to improve the security and
the resilience of your infrastructure
can be administratively burdensome
so this is where the PK unit protocol
comes into its own so PK unit stands for
public key cryptography
for initial authentication in kerberus
and with PK unit the client can use
asymmetric cryptography in the
authentication Service exchange to
authenticate to the KDC
the client presents an x509 certificate
and signs a message which is included in
the additional authentication
part of the
authentication Service request
and the KDC in processing that as
request
can verify the certificate
then verify the signature work out what
is The Binding between the the key of
the certificate and the principal
which is attempting to authenticate
and then if all of that checks out the
KDC will encrypt its response not using
the long term
uh session or sorry the long term secret
key of the client
but rather using diffie-hellman or some
analogous key agreement algorithm or
some other public key encryption
algorithm
so visualizing the PK init
authentication Service Exchange
this time the as request has quite a bit
more in it than just Halo it's me it's
client can I please authenticate
it includes
this first upper box and Authenticator
which includes the time stamp and if the
client wants to use diffie-hellman key
agreement to derive the
shared secret for encrypting the reply
then it will include a DH value that's
not required in all cases but this is
one of the more common variations of the
PK unit authentication Exchange
it also includes its x509 certificate
uh so the x509 certificate contains a
copy of the client's public key
and various other attributes
representing the client
as well as information about the public
key infrastructure who issued the
certificate
where can the ocsp responses be
retrieved from
or where is a crl so that the
KDC could perform revocation checking
and so on
so the KDC validates the signature
validates the certificate and the
certificate chain up to a trusted
um
trust anchor or root certificate
and
checks The Binding between the public
key and known principles or
the principle that is purporting to be
the one authenticating
and if that all checks out then it can
send a reply
which similar to the as reply when using
the standard shared secret
authentication it includes a randomly
generated session key
uh encrypted using in this case the
diffie-hellman value
and it includes a ticket granting ticket
as before the client will decrypt
the session key the TGs session key and
store the TGT
from this point on the rest of the
kerberus protocol is exactly the same as
explained previously so there's no more
use of the private key
there's no more use of any long-term
shared secret that's shared between the
client and the KDC
and everything uses symmetric
cryptography from here on
so what is the user experience of PK in
it well if you're using a CLI if you're
dealing with
services that want to use PK in it to to
grab a TGT then you can use the standard
kerberus or MIT kerberus client tools
the k-unit command and you just have to
provide some additional arguments to
explain while I'm using PK in it and you
can find my cert over there and my key
over here
um and there are
variations of this command if you want
to use a key stored in a pkcs11 module
for example
for a smart card or an HSM
and speaking of smart cards uh for a
user experience someone who wants to sit
down at a workstation and log in at the
start of the day you could use Smart
cards to do that
and sssd and it can integrate with your
Linux login managers like gdm it will
prompt for a pin for the smart card if
the slot requires a pin
and during the workstation login it
acquires the TGT so there's no further
user interaction required besides that
initial login
you can also configure your system to
log you out or lock the screen if the
smart card is detached
and I understand that the user
experience for Windows if you're using
PK unit in Windows environment is fairly
similar to what I've just described
to enable Smart Card login with sssd and
these commands are Fedora and Rel
specific but I imagine it will be
something similar for other
distributions
you can simply use the auth select
command to enable the with smart card
feature and if you wish the with smart
card lock-on removal feature
and if you say with smart card required
then that will require smart card login
exclusively for that workstation so
there'll be no option to fall back to
password authentication so in some high
security environments that might be
desirable
however if you leave your smart card at
home for the day you're going to have a
problem
you also have to update the sssd
configuration with a couple of options
to enable the Pam
the options for the Pam module to use
certificate Authentication
and with the free IPA provider
for sssd
you can
by default use an exact certificate
match only so this means that the
principles the user or the hosts uh
entry in the ldap database
has to have a user certificate attribute
containing the exact certificate being
used
so when the
sssd
and the KDC are processing the
certificate
it will use that exact certificate value
in an ldap search to find the principle
however this has some administrative
overhead when you're dealing with
renewals or revocations
in that anytime that happens and a new
certificate is issued an administrator
has to go or an automated system has to
go and update those entries the
alternative is certificate mapping rules
where we can use attributes in the
certificate to look up the principle for
example the user ID in the subject
distinguished name
or an email address or the subject DNS
name to look up a host for example
uh the caveat here is that at least in
the versions that I have tested
only one active mapping rule can be used
which is somewhat Limited
however it does avoid the administrative
overhead of having to update the
principles outlap entry every time a new
certificate is being issued
particularly if you have short-lived
certificates it can be much more
desirable to use certificate mapping
rules
and the client search can be signed by
the free IPA internal CA or by any
third-party CA you just have to add that
third party CA as a trusted uh route or
as a trust anchor doesn't have to be a
root certificate sometimes we'll
sometimes won't
but you have to just explicitly add that
CA as a trusted cert
demo time
okay
so
here is a workstation enrolled in
a free IPA domain this is all running on
a network of virtual machines on my
laptop here
so first of all their standard Kerberos
login experience so I'm going to use
password authentication logging in as
Alice
and so
Alice is logged in
whoa oh
it's going to get a bit more exciting
than that but uh just so that was using
uh password authentication
and uh if we run klist to list the
um the tickets that I have in my session
already
I have uh the TGT so the TGT was
acquired as part of their login
what can I do with a TGT well for
example I can hit any service that is
using Kerberos Authentication
I'll run an IPA command this is going to
hit free ipas HTTP API so I might just
say IPA I don't know user find Bob
is there a user called Bob in this org
ah what do you know there is and um
if we now run klist again we'll see that
in the background
and without any uh prompting to the user
a ticket was acquired for
um well the HTTP service running on
such and such a host which is one of the
IPA servers
uh I could also
talk to ldap
so why don't I do
ldap search
and
then search for
Bob again here
let's find out what Bob's email is
thank you very much William indeed it is
okay unsurprisingly Bob's mail is Bob at
ipa.test but again running k-list oh
what happened in the background we got a
ticket for the ldap service
so that's demonstrating the single
sign-on aspect of kerberus
so I'm now going to log out
and
um
I'm going to
attach a Ubi key to the VM so I've got a
UB key plugged into my laptop this
command is just to do the USB
passthrough so this is if you're using a
workstation not in a VM you wouldn't
have to do this
and attaching the UB key
haha not working
so let me just detach that
um
and work out why
hmm
nope
why not working
okay
let's try something else
all right
um
so it was actually working but for some
reason it wasn't detecting that a
certificate for Alice was on the smart
card and
um moving me straight to uh to this
prompt without any user interaction
which is what I was expecting to happen
didn't happen but the smart card is
working
so I'm going to put in the PIN
and press enter
okay so the login has succeeded
and again if we
take a list
and we've got a TGT so this was using
the PK init protocol to log into this
workstation and we have our initial TGT
and again
you know IPA user find Bob this TGT
acquired via PK unit is as good as a TGT
acquired using password authentication
in fact if you're using authentication
indicators it might even be a bit better
than such a ticket because it could
potentially allow access to Services
requiring a higher degree of assurance
or additional factors for the initial
Authentication
okay
so
um I'm just going to leave that session
as is for now
and jump back to the slides
so the advantages of PK unit well
there's no more shared Secret
the key can reside in a smart card as in
the demo or in a TPM or secure Enclave
in an HSM it could reside in a mobile
phone secure enclave and you could use
NFC if you have an NFC Reader on your
workstation
um the possibilities are really quite
many and varied
and the rest of the protocol after the
authentication Service exchange is
unchanged which means Services don't
need to do anything
and you still have the benefit of using
a more secure means of the initial
Authentication
but of course there are some
complexities so you need an x509 pki and
that's no small thing
and along with that comes the
comes the renewal considerations
um
so certificates have expiry dates how
long those certificates live really
depends on on your organization's policy
something like one year
for a user certificate
might be considered reasonable as a good
balance between making sure that
credentials don't live too long
versus
the burden of having to
issue new certificates too frequently
and revocation checking is hard to do
right and it can be introducing
additional latency into the protocol
while for example the KDC goes off and
talks to an ocsp server presenting the
certificate or the certificate serial
number and saying hey certificate
Authority is this certificate still
valid
when you're dealing with users people
who might be coming and leaving the
company getting fired
the revocation checking is really
potentially an extremely critical part
of the security posture of your pki in
general and your PK init deployment or
your Cobra deployment using PK units
specifically
if you want the additional security that
comes with putting your certificates on
Smart cards
UV keys
or for services into hsms or for the KDC
into an HSM then you will have
additional cost associated with the
hardware the setup the administration of
all of that but of course the
acquisition cost is much higher
and there is the thorny question of how
to establish or verify The Binding
between the public key and the principal
the RFC says this and I'll just focus on
this first sentence the KDC must capital
m capital u capital S capital T also
check that the client's public key used
to verify the client's signature is
bound to the client principal name
specified in the as request
note also client principal name
specified in the as request so the
principle that the client says it is
is something supplied by the client hmm
interesting okay so there are several
ways to do this you can encode the
principal name directly in the
certificate using a krb5 principal name
subject alternative name value in
Microsoft environments there's also the
UPN San name type
you can associate the certificate or the
key directly with the principle in the
database
this is the exact certificate matching
that I described for free IPA as the
default Behavior
and uh yeah I mentioned the
administrative overheads that arise in
that scenario but it is quite secure
and you can use other heuristics for
example if the certificate has a DNS
name subject alt name then we can look
for a host principle with that name if
it has an RFC 822 name an email address
then maybe we look for the user with
that email address in the database but
the long and the short of it is you'd
better not mess this up either in the
policy or in the implementation
oh hmm okay so cve 2022 4254 uh demo
time let me not get ahead of myself so
um
let me just change into this ominously
named directory
um
let me do an IPA
um
user find Alice so by the way I'm Alice
right now okay
Alice at ipa.test
um hands up how many people work in an
organization where you can request your
own email address or your own mail alias
so a few hands up like maybe a quarter
of the room so this is reasonably common
and even more common in kind of I.T or
technology focused organizations
um that a user can say hey I would like
such and such to be my email address
um maybe you even have an automated
system for doing that
um
Alice's organization has such a system
and uh this system just checks the
uniqueness
of the
of the email address and also that it is
a syntactically valid
email address according to RFC 822 or
its successes
so
here's Alice's email alias
and uh then Alice
requested a certificate
and the CSR
uh
um the CSR
uh has common name Alice okay yep that
that all seems very reasonable
oh but also an rfca22 name with that
email address
um
and the certificate that the ca issued
um helpfully
propagated that email address
uh to the final certificate checking of
course that that was in fact one of
Alice's email addresses as recorded in
Alice's ldap entry
so what can we do now with this
certificate hmm
let's see
um why don't we do a K in it Dash X
509
user identity
equals file
naughty.com and the corresponding key
naughty dot key
ah oh hang on a minute
and uh I want to be admin laughs
and oh I got a TGT
for the guard user so this is
um a complete domain takeover attack
um so
what just happened
uh it's an ldap filter injection attack
as you might have gathered
by the presence of the suspicious
characters in The syntactically valid uh
RFC 822 name or email address
free IPA is not vulnerable to this in
its default configuration because in the
default configuration only exact
certificate matches enabled by default
but if you do use cert map rules
and if your cert map rule
is constructed in such a way
that might enable some
misinterpretation of the structure of
that filter based on the unescaped
special characters in The RFC 822 name
then you've got a big big problem
when I discovered this it was
only present in older versions of sssd
it had already inadvertently been fixed
um as it had been recognized as a bug
but the security implications of that
bug were not recognized at that time
so there's a range of sssd versions that
were vulnerable
and they have now been fixed
um you can also
attack it in other ways for example if
you have a certificate with a DNS name a
wildcard DNS name that unescaped wild
wild card means something else in ldap
it's a substring match
so if you had a certificate
I don't know for a web host in your
organization who's Sandy and S name was
star.ipa.test then using that
certificate you could get a TGT for any
other host in the organization whose
host name is
something.ipa.test including your IPA
servers if they happen to have a
matching host name so
this is
perhaps a bit more
plausible or likely to be
out there in the real world than the um
than the email address related attack
that I demonstrated I've talked about
the email address attack that will only
work if your cert map rule has an or
Clause because all of the um
all of the Clauses in an and clause or
if it's only a single filter expression
would have to be matched but in an all
Clause only one can be matched so it
gives the attacker a bit more
flexibility in kind of what sort of
content they can try and inject into the
ldap filter and still mount a successful
attack
um so in the email address attack this
is what the final filter ends up looking
like
so we see this all expression and you
know mail equals bogus uid equals admin
CN equals such and such and so that
single matching uid equals admin Clause
is
what caused the
domain to get owned
so the mitigations of course upgrade to
the patched releases and list rules are
harder harder to exploit than the all
list rules so you may be able to change
the structure of the rules
you should certainly audit what data
gets included in certs and how
and exact certificate matching
albeit with its administrative overheads
is uh not vulnerable at all to this
attack
so security considerations properly
Escape or sanitized all of your inputs
all of the time that's just a general
rule in all of Technology
review your ca trust the certificate
profiles and the validation Behavior
and just because of value is valid like
that email address does not mean that it
is benign
in summary the key in principle binding
is a critical aspect of PK in its
security it is as critical as validating
the signature in the as request and
validating the certification path up to
a trusted CA
uh some resources uh there's a write-up
of the vulnerability on my blog at that
is good link and also the official entry
in the cve database and just a shout out
to a related method uh sorry a related
effort of introducing 502 and web authon
support to free IPA and kerberus which
is where you'll be able to use web
authen Hardware tokens to perform that
initial authentication this
doesn't have the expiry and revocation
capabilities that PK init does but it
might be a good option in the future
once this is delivered for some
organizations as an alternative to PK in
it to get more Security in your kerberus
deployment
that's the end hopefully there's time
for one or two questions
[Applause]
thank you very much Fraser our actual
official time is up but I'm we're coming
on to lunchtime so I think we can
probably manage one or two questions
of course I have a question uh it's
actually a little bit tangential but
when you did the prv authentication with
the pass through ubiki did you actually
need to do the interaction with the
device for that signature to be released
or does it not require the interaction
where you touch it
uh
no it in this case it does not require
the interaction because this UB key has
specifically been put into PIV mode so
ubiques have different modes it's got a
like a u2f or a Web author mode it has a
PIV mode that brings me to bonus slide
what is PIV uh PIV is a smart card
standard from nist and there's also some
mention there of some other related
smart cards concerning the hardware
you mentioned issues with crls and
latency of the logins Etc
um
what do you see is the problem with just
disabling users on the server versus
versus worrying about crls
right thank you for the question
um it really depends on how the binding
is done it's a matter of the kdc's
implementation and policy
so if you have for example certificates
with the principal encoded in them
uh in the krb5 principle name subject
alt name field then a KDC doesn't
necessarily have to go looking up that
user in an ldap database
in any case the ldap database
would typically be local to the KDC
certainly in free IPA it always is so
that every IPA server in a topology has
a KDC instance and an ldap instance and
they they talk just over a local socket
so talking to the ldap server is fast
potentially a lot faster than
talking to the
ocsp server but yeah in this case
um
I'm not sure what happens in the free
IPA implementation but it could check
whether the user has been disabled there
or not
there exists many ways to configure and
deploy MIT Kerberos and whatever other
implementations out there I'm not sure
what they do but if the principles
encoded in the cert the KDC could use it
as is subject to revocation checking in
that case the latency of the revocation
check
um or the in the case of ocsp which is
an online revocation check versus
um
not doing any revocation checking could
in a large deployment be a factor
impairing the the usefulness or the user
experience of using PK unit
there is an extension for
clients to
include an ocsp response
in the
as request so you would call that ocsp
stapling if you're familiar with that in
a web context
the standards exist for doing the same
thing in PK init but I don't know how
widely implemented they are I certainly
don't know how to do it on
on the systems that I use
well thank you very much again
afraid we don't have time to take any
more questions if you have questions uh
come talk to me I'll answer them now to
the best of my ability
thank you
[Applause]