Make it possible to optionally enable Anonymous PKINIT support for FreeIPA KDC by allowing to associate a certificate with krbtgt/REALM@REALM principal and allow IPA masters to issue this certificate, and by creating anonymous principal in the KDC.
Add a tool, either in ipa-advise or as a separate one, to enable existing environments to serve Anonymous PKINIT.
Can we please add some user story? If this feature is added what workflows would become possible?
Alternative way to PAKE to enable "credential upgrade". Useful in combination with kerberos indicators #433.
Alexander, could you specify here how end user would then use it.
Primary user story is to allow users to authenticate with 2FA in cases when there is no access to host keys. In order to kinit when 2FA is enabled for the user account, a FAST channel needs to be created to pass the second factor credentials. Without access to existing keys it is impossible to achieve without anonymous PKINIT.
Anonymous PKINIT would enable obtaining a TGT without need for a separate key. Received TGT cannot not be used to ask for any service ticket (this is controlled by KDC configuration) but can instead be used to create an encrypted FAST channel to authenticate actual user with 2FA.
Another use for anonymous PKINIT is for anonymously identifying whether certain principal is known by the KDC either natively or via cross-realm trust. This is something we want to enable in future for browsers to allow secure probing of unknown web sites.
Below is a small example. A non-privileged user can obtain a TGT as anonymous user and later upgrade it to a proper TGT with 2FA:
[abbra@client ~]$ klist klist: Credentials cache keyring 'persistent:1792600003:1792600003' not found [abbra@client ~]$ kinit kinit: Invalid argument while getting initial credentials [abbra@client ~]$ kinit -n [abbra@client ~]$ klist -Aef Ticket cache: KEYRING:persistent:1792600003:1792600003 Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS Valid starting Expires Service principal 02/23/2016 19:22:18 02/24/2016 19:22:18 krbtgt/VDA.LI@VDA.LI Flags: FIAa, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 [abbra@client ~]$ kinit -T KEYRING:persistent:1792600003:1792600003 abbra@VDA.LI Enter OTP Token Value: [abbra@client ~]$ klist Ticket cache: KEYRING:persistent:1792600003:krb_ccache_TvMr0nX Default principal: abbra@VDA.LI Valid starting Expires Service principal 02/23/2016 19:28:07 02/24/2016 19:27:49 krbtgt/VDA.LI@VDA.LI
What certificate is expected in this case? Is it just a public cert of the server or something else?
The one accepted via pkinit_anchors. For example, for FreeIPA default configuration we trust IPA CA, thus a certificate issued by it will just work fine.
My prototype code used a certificate obtained by certmonger:
ipa-getcert request -k /etc/certmonger/clients/kdc/kdc.key -f /etc/certmonger/clients/kdc/kdc.crt -N cn=id.vda.li -K krbtgt/VDA.LI@VDA.LI
Key point here is to be able to assign this certificate to the krbtgt/REALM@REALM principal. In this case Kerberos client will not need any Kerberos-specific EKU for certificate verification.
4.4.0 was released, moving open tickets to 4.4.1
Moving to next major version. Fixing this bug is not critical in stabilization release.
master:
Metadata Update from @abbra: - Issue assigned to simo - Issue set to the milestone: FreeIPA 4.5
Metadata Update from @jcholast: - Custom field affects_doc reset - Custom field tester adjusted to wanted - Issue close_status updated to: None (was: Fixed)
Login to comment on this ticket.