Hide Forgot
Starting RHEL 7.3 IdM can issue tickets that include authentication indicators. These indicators are strings that are added into the kerberos ticket by the KDC. These strings indicate how the authentication was conducted in the first place. Indicators allow services to do additional authorization checks based on the way how the authentication have been conducted. User stories: - As an administrator I want to allow Kerberos based login using GSSAPI only for users that conducted authentication in a specific way, for example using 2FA with OTP or using PKINIT based on the smart card authentication. - As an administrator I want to optionally allow services that use keytabs to be able to access a system. I do not want to be required to list all the services in the configuration files explicitly. The implementation should consider using GSSAPI extensions that are being added upstream to retrieve indicators from the ticket.
The idea of the configuration option name was GSSAPIAllowedAuthIndicators (I would rather be for something like GSSAPIRequiredAuthIndicators). The documentation [1] is quite brief. I see there can be set require_auth attribute on the server principal entries, which does basically the same thing in the kerberos directly. I would like to keep the wording and semantics similar. Therefore the new option should accept the space-separated list of authentication indicators that are allowed to access the system. Quote from [1]: > 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. We should be able to get the “auth-indicator” attribute using gss_get_name_attribute() [2] function call. Please review if my understanding is correct or I miss something. I will try to triage this task for RHEL7.4 [1] https://k5wiki.kerberos.org/wiki/Projects/Authentication_indicator [2] https://tools.ietf.org/html/rfc6680#section-7.5
Few questions I was unable to find an answer for about the authentication indicators. They are set as a single value separated with space, or more separate values (multi-valued name attributes) returned by the call to gss_get_name_attribute()? Also I would be interested if the other approach, not granting TGT if the AI are not in satisfied in the principal, would be possible and what other pros and cons would come in the case of SSH? Is there any way to see the authentication indicators from the user point of view, using klist or something similar?
(In reply to Jakub Jelen from comment #2) > Few questions I was unable to find an answer for about the authentication > indicators. > > They are set as a single value separated with space, or more separate values > (multi-valued name attributes) returned by the call to > gss_get_name_attribute()? They should be multiple separate values. > Also I would be interested if the other approach, not granting TGT if the AI > are not in satisfied in the principal, would be possible and what other pros > and cons would come in the case of SSH? A KDC could either not provide a TGT if the required preauthentication method is not used, or it could theorethically refuse to provide service tickets for specific services if the required AI identifier is not in the TGT. But no implementation provides this kind of filtering yet, in any case it would all happen before any involvement of SSH and the result would be an error when attempting to obtain a ticket for the target server. > Is there any way to see the authentication indicators from the user point of > view, using klist or something similar? No I do not think klist has any switch to show named attributes associated with tickets.
Simo, thank you for fast feedback. (In reply to Simo Sorce from comment #3) > A KDC could either not provide a TGT if the required preauthentication > method is not used, or it could theorethically refuse to provide service > tickets for specific services if the required AI identifier is not in the > TGT. But no implementation provides this kind of filtering yet, in any case > it would all happen before any involvement of SSH and the result would be an > error when attempting to obtain a ticket for the target server. That was clear. But I guess this would not fit the second requirement above, because this would need some other configuration: > I do not want to be required to list all the services in the configuration files explicitly. I got through some GSSAPI documentation (Oracle [1] quite helped this time) and put together some proof of concept ready to test if I will have some time before Christmas to set up kerberos in my virtual machine. [1] https://docs.oracle.com/cd/E19683-01/816-1331/overview-6/index.html
Simo, do you know if we can set up authentication indicators to to arbitrary kerberos ticket, or is it only possible to use from OTP and PKINIT at this moment? Anyway, the proof of concept is here (there is still space to improve/cleanup so comments welcome): https://github.com/Jakuje/stuff/blob/master/openssh_gssapi_auth_indicators.patch So far I was able to test the case it rejects the connections without authentication indicators. So the request looks possible to solve with some more tweaks. Lets give it some more time to decide if we want it, want it in this form, and give it some more testing. Setting up OTP itself is quite big work but in the end, I could install IPA to see if it already works there.
There is a test module in the MIT test suite to set arbitrary stuff, but it is not shipped of course. The patch looks reasonable. CCing Matt who may have more advice on how to properly test this with a vanilla KDC.
Thanks for the comment. The attribute name should be fixed now. Setting up whole OTP in automated testing is probably overkill for OpenSSH testing. But our QE (and me) will certainly want to put together automated test case for this feature. In "worst" case, we can build test module to take care of that. But even with this test module from krb5 master I was unable to get any authentication indicator to that ticket. * I added the module to the krb5.conf [plugins] kdcpreauth = { module = test:/root/trunk/krb5/src/plugins/preauth/test/test.so } clpreauth = { module = test:/root/trunk/krb5/src/plugins/preauth/test/test.so } * Added preauth requirement for tester user * I run kinit with -X indicators=strong From my testing I am ending up with GSS_S_UNAVAILABLE return value from gss_get_name_attribute() which basically explains that there are not authentication indicators in the ticket. Can you point me out: * Is is possible to set indicators using -X switch in the kinit? * What options needs to be set up except the test module? * Is there some logging from the modules used in KDC? Or am I looking to the completely wrong? Is is simpler to set up pkinit?
This issue was not selected to be included either in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small amount of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.