Projects/Authentication indicator
This project will implement a way to restrict access to services based on how the initial authentication was performed.
Contents
Background
Kerberos deployments may support pre-authentication mechanisms, such as PKINIT or OTP, which may confer a higher level of confidence in the authentication than the use of a password alone. A deployment may wish to require that some resources can only be accessed using tickets which were obtained using high-confidence pre-authentication.
Currently, the most practical way to enforce this requirement is to make sure that certain principals can only authenticate using high-confidence pre-authentication, and then grant resource access only to those principals. Such principals may be separated from the principals used for day-to-day activities of the end-user by giving them different names (e.g. ghudson/root@ATHENA.MIT.EDU as opposed to ghudson@ATHENA.MIT.EDU), at the cost of complicating realm administration and auditing.
This project will implement a means of restricting access without requiring that a principal always authenticates using high-strength pre-authentication, by marking how the ticket was initially obtained. The Kerberos protocol defines several existing methods for doing this, none of which are sufficiently general:
- The pre-authent ticket flag indicates that some form of prea-authentication was used, but does not indicate what it was.
- The hw-authent ticket flag was intended to indicate that a hardware device was used during pre-authentication. It is rarely used, as the KDC usually cannot tell whether a client used a software or hardware device to produce a certificate or OTP token value. While it could be re-purposed to mean "high-confidence pre-authentication" in general, it would still be poorly defined and not very granular.
- PKINIT (RFC 4556) defines the AD_INITIAL_VERIFIED_CAS authdata type, which shows the certification path of the client certificate. This type is specific to PKINIT, and would be cumbersome for an application server to use as it would have to be configured with specific knowledge about PKINIT certification authorities. There is no equivalent for FAST OTP.
- RFC 6113 defines AD-authentication-strength, which contains the numeric codes of the pre-authentication types used to authenticate the client, and possibly additional information for each type (but no additional information is currently defined). Again, to use this element, an application server would have to be configured with specific knowledge about pre-authentication mechanisms and the confidence they confer.
This project will instead use the AUTHENTICATION-INDICATOR element defined in draft-jain-kitten-krb-auth-indicator. The intent of this element is that the KDC makes a determination about pre-authentication confidence at the time of initial authentication, and communicates this to services via one or more site-defined string values. The AUTHENTICATION-INDICATOR element is carried within a CAMMAC (draft-ietf-krb-wg-cammac), which allows it to be carried from the evidence ticket of an S4U2PROXY request into the delegated ticket.
Design
This project requires five elements:
- Encoding and decoding CAMMACs and AUTHENTICATION-INDICATORs
- Deciding on indicators for a preauthentication
- Generating authdata for an initial ticket
- Re-signing the CAMMAC across TGS and S4U2PROXY requests
- Enforcing indicator restrictions within the KDC
Across several of these elements, we will have a choice of whether to use the existing KDB interface hooks for authdata ("KDB-centric") or to handle the element within the core code ("core-centric").
Enforcing indicator restrictions on application servers is out of scope for this project.
ASN.1 encoders and decoders
We will require ASN.1 encoders and decoders for the CAMMAC and AUTHENTICATION-INDICATOR elements. Commit a7dc565cafbaa6c18d5a76ea3cc823c7159a0d6b can be used as a reference for what files need to be modified to add new types.
We will likely want a public libkrb5 API for manipulating CAMMACs, like we have for PACs.
Deciding on authentication indicators
The KDC will need some way of deciding on zero or more authentication indicator strings based on a successful pre-authentication. It must take into account the particulars of the pre-authentication mechanism as well as site preferences.
The simplest approach would be to allow each kdcpreauth module to be able to yield authentication indicators via a callback, and in each module to implement code to yield indicators based on configuration. PKINIT might have configuration to produce indicators based on certificate attributes and/or the signing authority, OTP based on the token type, etc.. This approach would be easily used out of the box (not necessarily valuable in a KDB-centric design), but would not be any more flexible than the code in the kdcpreauth modules.
A more complicated approach would have each module producing detailed parameters (PKINIT certificate and signing chain, OTP request and token type, etc.). In a KDB-centric design, these parameters could be provided to the sign_authdata method. In a core-centric design, a new plugin interface could be created to generate indicators based on preauth parameters. Either way, the processing layer would require knowledge of each mechanism's specific parameters to make a decision.
Generating indicator authdata for initial tickets
In a KDB-centric design, this would be the job of the KDB module's sign_authdata method, just as it is for PACs.
In a core-centric design, we would create a new static authdata system in kdc_authdata.c which generates an AUTHENTICATION-INDICATOR and signed CAMMAC.
Preserving CAMMAC across TGS and S4U2PROXY requests
In a KDB-centric design, this would be the job of the KDB module's sign_authdata method, just as it is for PACs.
In a core-centric design, we would extend handle_tgt_authdata in kdc_authdata.c to detect a CAMMAC in the TGT or evidence ticket, validate it, and re-sign it for the result ticket. It may not always be appropriate to blindly re-sign all authdata contained within a CAMMAC, but for now we can make that assumption if the CAMMAC was signed with the local realm TGT.
(Open question: does it make sense to propagate an authentication indicator for a cross-realm TGS request?)
Enforcing indicator restrictions on the KDC
At this stage, all indicator enforcement takes place within the KDC's ticket-granting service.
In a KDB-centric design, this would be the job of the KDB module's check_policy_tgs method.
In a core-centric design, we would create a new pluggable interface for KDC policy. A KDC policy module would be able to access the authentication indicator within the CAMMAC in the TGT, and deny access to certain services based on the lack of particular indicators.
