logo_kerberos.gif

Difference between revisions of "Projects/Authentication indicator"

From K5Wiki
Jump to: navigation, search
Line 1: Line 1:
 
{{project-early}}
  
{{project-early}}
  +
{{project-target|1.14}}
   
 
This project will implement a way to restrict access to services based on how the initial authentication was performed.
  
This project will implement a way to restrict access to services based on how the initial authentication was performed.
Line 21: Line 22:
 
==Scope==
  
==Scope==
   
−
This project will implement the AUTHENTICATION-INDICATOR element defined in {{idref|draft-jain-kitten-krb-auth-indicator}}. 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 ({{idref|draft-ietf-krb-wg-cammac}}), which allows it to be carried from the evidence ticket of an S4U2PROXY request into the delegated ticket.
 +
This project will implement the AUTHENTICATION-INDICATOR element defined in {{idref|draft-ietf-kitten-krb-auth-indicator}}. 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 ({{idref|draft-ietf-kitten-cammac}}), which allows it to be carried from the evidence ticket of an S4U2PROXY request into the delegated ticket.
   
−
Access restriction based on AUTHENTICATION-INDICATOR may take place either within KDC through its ticket policy or on the application server itself. The latter allows more fine-grained access control, but also requires changes to application server code. This project will cover only enforcement on the KDC; enforcement on application servers will be a follow-on project.
 +
Access restriction based on AUTHENTICATION-INDICATOR may take place either within a KDC through its ticket policy, or on the application server itself. The latter option allows more fine-grained access control, but also requires changes to application server code. This project will cover only enforcement on the KDC; enforcement on application servers will be a follow-on project.
   
 
This project must be useful with the built-in KDB modules. A third-party KDB module may provide additional input into the process, but basic functionality must be present in the core system.
  
This project must be useful with the built-in KDB modules. A third-party KDB module may provide additional input into the process, but basic functionality must be present in the core system.
Line 29: Line 30:
 
==Design==
  
==Design==
   
−
This project requires five elements:
  
  +
===Structural improvements===
   
−
* Encoding and decoding CAMMACs and AUTHENTICATION-INDICATORs
  
  +
The KDC authorization data facilities currently center around a private pluggable interface which predates [[Projects/Plugin support improvements]]. All internal operations are funneled through that interface's function signature. This interface will be converted to a new-style pluggable interface, which will remain private. Internal operations will be decoupled from the interface and will be directly invoked from handle_authdata(), using signatures tailored to the needs of the specific operation.
−
* 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
  
   
−
===ASN.1 encoders and decoders===
  
  +
AS and TGS requests often load a krbtgt principal entry as part of their processing, but do not always. The current authorization data code makes the assumption that the AS server principal or TGS header ticket server principal are krbtgt principals, and that the principal loaded has the same current key data as for previous operations on the ticket. As a result, there are some obscure bugs in AD-SIGNTICKET processing, and there would be similar bugs in CAMMAC processing if we followed the same assumption. The KDC code will be augmented to load the server realm's local krbtgt principal if it was not already loaded, and the AD-SIGNTICKET code will use that principal entry for its checksums.
   
−
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.
  
  +
===CAMMAC and indicator encoding===
   
−
We will likely want a public libkrb5 API for manipulating CAMMACs, like we have for PACs.
  
  +
Private ASN.1 encoders and decoders for CAMMACs and sequences of UTF-8 strings (for auth indicators) will be added to lib/krb5/asn.1.
   
−
===Deciding on authentication indicators===
  
  +
The KDC will contain functions to generate and verify CAMMACs and to manage lists of authentication indicators. Public interfaces for these data types are not required for the current phase of the project.
   
−
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 CAMMAC specification allows the kdc-verifier and svc-verifier to be omitted in certain cases. The initial implementation will not include those space optimizations.
   
−
The simplest design would allow each kdcpreauth module to generate authentication indicators via a new callback, and use mechanism-specific configuration to determine what indicators to generate. For instance, OTP could have a token type configuration element to generate an authentication indicator when that token type is successfully used. However, this design is only as flexible as the code we write in kdcpreauth modules. For PKINIT in particular, it would be difficult to capture all of the ways that certificates could influence authentication indicators--although we are separately considering a PKINIT sub-interface for certificate authorization which could be reasonable extended for this purpose.
  
  +
===Deciding on indicators===
   
−
A more complicated and flexible approach would have each module producing detailed parameters (PKINIT certificate and signing chain, OTP request and token type, etc.). These parameters could be provided to a KDB method and/or to a new pluggable interface module in order to generate indicators. Modules will require knowledge of each mechanism's specific parameters to make a decision. A default module could generate indicators based on configuration and the mechanisms used.
  
  +
The kdcpreauth interface will receive a new callback which allows a module to assert an authentication indicator. The OTP and PKINIT kdcpreauth modules will read configuration options which cause them to assert indicators.
   
−
===Generating indicator authdata for initial tickets===
  
  +
In the future, the KDB module (or a future KDC module type) could participate in this decision based on parameters generated by the kdcpreauth module. Such a facility is not in scope for the initial implementation.
   
−
kdc_authdata.c will be refactored for simplicity and improved maintainability.
  
  +
===AS and TGS requests===
   
−
In kdc_authdata.c, handle_authdata will be amended to generate an AUTHENTICATION-INDICATOR and signed CAMMAC if any authentication indicators are generated by the preauthentication process.
  
  +
During AS request processing, indicators may be asserted by kdcpreauth modules. These indicators will be passed to handle_authdata(), encoded as sequence of UTF-8 strings, and wrapped in CAMMAC and IF-RELEVANT containers for the issued ticket.
   
−
===Preserving CAMMAC across TGS and S4U2PROXY requests===
  
  +
During TGS request processing, indicators will be extracted from the header ticket for normal TGS requests, from the evidence ticket for S4U2Proxy requests, and not at all for S4U2Self requests. Any extracted indicators will be included in the issued ticket.
   
−
In kdc_authdata.c, copy_tgt_authdata (renamed from handle_tgt_authdata) will detect a CAMMAC in the TGT or evidence ticket, validate it, and re-sign it for the result ticket. If the CAMMAC was signed by a different server, the CAMMAC contents will be filtered to include only AUTHENTICATION-INDICATOR elements, as we do not know in general whether it is safe in general to vouch for another KDC's authorization assertions.
  
  +
Cross-realm support requires a certain measure of trust in the remote realm to accurately represent how that realm's clients authenticated. It may also be necessary to translate indicator values if the two realms do not use the same naming semantics. For the initial implementation, indicators will not be accepted from cross-realm TGS header tickets. In the future a string attribute may be added to authorize a cross-realm TGS principal to propagate specific indicator values. Translation of values will probably need to be performed by a plugin module (perhaps the KDB module); this feature is also deferred to the future.
   
−
===Enforcing indicator restrictions on the KDC===
  
  +
===Indicator enforcement===
   
−
We can add a new principal attribute, perhaps using string attributes, which deny access to the principal as a server unless a specified authentication indicator is present.
  
  +
For either an AS or TGS request, if the server principal has the require_auth string attribute set, one of the indicators listed in the attribute value must have been asserted or the KDC will reject the request with a policy error.
   
−
More generally, we can 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.
  
  +
A service with a required indicator will currently fail all S4U2Self operations, because the real client did not authenticate and therefore no indicator was asserted. In the future, we may develop a simple protocol for services to request indicators to be asserted during S4U2Self operations, and a simple authorization framework for the KDC to decide what indicators a service is allowed to assert (probably the same authorization framework as for cross-realm indicator suport).
   
−
The KDB module's check_policy_tgs method can also contribute to this decision.
  
  +
In the future the KDB module (or perhaps a future KDC policy module) could participate in this decision. This feature is not part of the initial implementation.
  +
  +
==Testing==
  +
  +
As part of the KDC authdata refactoring work, a C harness will be written for the tests directory which obtains a service ticket with optional request authdata, decrypts it, and displays the leaf authdata contained in the ticket with annotations for any authdata container along the path to the leaf. Tests will be written to verify most of the existing logic for including authdata in the ticket.
  +
  +
Currently, test scripts cannot easily simulate successful S4U2Proxy operations as the default KDB module always rejects constrained delegation requests. A read-only test KDB module will be written which can be used to exercise this and other KDC behavior. The module will read all of its results from the profile, making it easy to control them from the test script.
  +
  +
A test preauth module will be written so that test scripts can easily control the authenticated indicators asserted during an AS request without having to set up PKINIT or OTP. The clpreauth module will transmit the desired indicators (specified using kinit -X) to the kdcpreauth module, which will assert them without performing any meaningful preauthentication.
  +
  +
Currently S4U2Proxy can only be tested by using the GSSAPI harnesses in tests/gssapi, or by using kvno -P which requires also performing S4U2Self. A simple S4U2Proxy test harness will be written for the tests/ directory.
  +
  +
Tests will be written to cover the major cases: AS requests to the local TGS, cross TGS, and service principals; regular TGS requests to the local TGS, cross TGS, and service principals; ticket modifications requests; S4U2Self requests; and S4U2Proxy requests.
  +
  +
==Documentation==
  +
  +
A new page admin/auth_indicator.rst will document how to use auth indicators within a realm. The new kdcpreauth callback, configuration variables, and string attributes will be documented in the appropriate places.
  +
  +
==References==
  +
  +
{{bug|8157}}
  +
(TBD list discussions, probably mostly on kitten)
  +
  +
==Commits==
  +
  +
TBD (test KDB module already done)
  +
  +
==Release notes==
  +
  +
TBD

Revision as of 12:41, 25 March 2015

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


This project is targeted at release 1.14.


This project will implement a way to restrict access to services based on how the initial authentication was performed.

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.

Scope

This project will implement the AUTHENTICATION-INDICATOR element defined in draft-ietf-kitten-krb-auth-indicator. 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-kitten-cammac), which allows it to be carried from the evidence ticket of an S4U2PROXY request into the delegated ticket.

Access restriction based on AUTHENTICATION-INDICATOR may take place either within a KDC through its ticket policy, or on the application server itself. The latter option allows more fine-grained access control, but also requires changes to application server code. This project will cover only enforcement on the KDC; enforcement on application servers will be a follow-on project.

This project must be useful with the built-in KDB modules. A third-party KDB module may provide additional input into the process, but basic functionality must be present in the core system.

Design

Structural improvements

The KDC authorization data facilities currently center around a private pluggable interface which predates Projects/Plugin support improvements. All internal operations are funneled through that interface's function signature. This interface will be converted to a new-style pluggable interface, which will remain private. Internal operations will be decoupled from the interface and will be directly invoked from handle_authdata(), using signatures tailored to the needs of the specific operation.

AS and TGS requests often load a krbtgt principal entry as part of their processing, but do not always. The current authorization data code makes the assumption that the AS server principal or TGS header ticket server principal are krbtgt principals, and that the principal loaded has the same current key data as for previous operations on the ticket. As a result, there are some obscure bugs in AD-SIGNTICKET processing, and there would be similar bugs in CAMMAC processing if we followed the same assumption. The KDC code will be augmented to load the server realm's local krbtgt principal if it was not already loaded, and the AD-SIGNTICKET code will use that principal entry for its checksums.

CAMMAC and indicator encoding

Private ASN.1 encoders and decoders for CAMMACs and sequences of UTF-8 strings (for auth indicators) will be added to lib/krb5/asn.1.

The KDC will contain functions to generate and verify CAMMACs and to manage lists of authentication indicators. Public interfaces for these data types are not required for the current phase of the project.

The CAMMAC specification allows the kdc-verifier and svc-verifier to be omitted in certain cases. The initial implementation will not include those space optimizations.

Deciding on indicators

The kdcpreauth interface will receive a new callback which allows a module to assert an authentication indicator. The OTP and PKINIT kdcpreauth modules will read configuration options which cause them to assert indicators.

In the future, the KDB module (or a future KDC module type) could participate in this decision based on parameters generated by the kdcpreauth module. Such a facility is not in scope for the initial implementation.

AS and TGS requests

During AS request processing, indicators may be asserted by kdcpreauth modules. These indicators will be passed to handle_authdata(), encoded as sequence of UTF-8 strings, and wrapped in CAMMAC and IF-RELEVANT containers for the issued ticket.

During TGS request processing, indicators will be extracted from the header ticket for normal TGS requests, from the evidence ticket for S4U2Proxy requests, and not at all for S4U2Self requests. Any extracted indicators will be included in the issued ticket.

Cross-realm support requires a certain measure of trust in the remote realm to accurately represent how that realm's clients authenticated. It may also be necessary to translate indicator values if the two realms do not use the same naming semantics. For the initial implementation, indicators will not be accepted from cross-realm TGS header tickets. In the future a string attribute may be added to authorize a cross-realm TGS principal to propagate specific indicator values. Translation of values will probably need to be performed by a plugin module (perhaps the KDB module); this feature is also deferred to the future.

Indicator enforcement

For either an AS or TGS request, if the server principal has the require_auth string attribute set, one of the indicators listed in the attribute value must have been asserted or the KDC will reject the request with a policy error.

A service with a required indicator will currently fail all S4U2Self operations, because the real client did not authenticate and therefore no indicator was asserted. In the future, we may develop a simple protocol for services to request indicators to be asserted during S4U2Self operations, and a simple authorization framework for the KDC to decide what indicators a service is allowed to assert (probably the same authorization framework as for cross-realm indicator suport).

In the future the KDB module (or perhaps a future KDC policy module) could participate in this decision. This feature is not part of the initial implementation.

Testing

As part of the KDC authdata refactoring work, a C harness will be written for the tests directory which obtains a service ticket with optional request authdata, decrypts it, and displays the leaf authdata contained in the ticket with annotations for any authdata container along the path to the leaf. Tests will be written to verify most of the existing logic for including authdata in the ticket.

Currently, test scripts cannot easily simulate successful S4U2Proxy operations as the default KDB module always rejects constrained delegation requests. A read-only test KDB module will be written which can be used to exercise this and other KDC behavior. The module will read all of its results from the profile, making it easy to control them from the test script.

A test preauth module will be written so that test scripts can easily control the authenticated indicators asserted during an AS request without having to set up PKINIT or OTP. The clpreauth module will transmit the desired indicators (specified using kinit -X) to the kdcpreauth module, which will assert them without performing any meaningful preauthentication.

Currently S4U2Proxy can only be tested by using the GSSAPI harnesses in tests/gssapi, or by using kvno -P which requires also performing S4U2Self. A simple S4U2Proxy test harness will be written for the tests/ directory.

Tests will be written to cover the major cases: AS requests to the local TGS, cross TGS, and service principals; regular TGS requests to the local TGS, cross TGS, and service principals; ticket modifications requests; S4U2Self requests; and S4U2Proxy requests.

Documentation

A new page admin/auth_indicator.rst will document how to use auth indicators within a realm. The new kdcpreauth callback, configuration variables, and string attributes will be documented in the appropriate places.

References

[krbdev.mit.edu #8157] (TBD list discussions, probably mostly on kitten)

Commits

TBD (test KDB module already done)

Release notes

TBD

Retrieved from "https://k5wiki.kerberos.org./wiki?title=Projects/Authentication_indicator&oldid=5461"