Holder of Key

About

The phrase "Holder of Key" (HoK) has two meanings in the context of SAML. It is a SAML Subject Confirmation Method, and in this capacity it is supported by many SAML products and is in use today in the case of Web Services based SAML transactions.

The second use of this term refers to the SAML Holder-of-Key Web Browser SSO Profile. This profile defines a method for using the Holder-of-Key subject for generalized browser SSO achieving significant security enhancements over any other federated browser based user SSO.

This SAML profile has no implementations today.

Value

• Allows LoA3 and LoA4 federated SSO.
• Browser based and should work for users.
  • Could be used for REST based Web Services as well to heighten their security.
• Could simplify attribute exchange expanding authorization capabilities when authentication is possible without SAML.
• Increases the value of a user having a certificate based credential as it can be used for broader purpose.
  • It could simplify certificate management for highly credentialed users, as a single certificate could get them access to more systems, where as before they had many individual credentials.
• The TLS 1.1+ capabilities are only mandatory server-side. TLS 1.0 clients can interoperate. Most Browsers should exceed TLS 1.0 compatibility.

Challenges

• Usability concerns for how browsers prompt users for anonymous certificates.
  • Experimentation and prototypes are necessary to do determine the scope of this challenge.
  • Will browser plug-ins be necessary to help users?
  • If users only have a single certificate (which may be a longterm goal of HoK SSO), this may be a non-issue.
• There is no demand for this capability in the education community, as users do not have certificates; they have usernames and passwords.
  • Interested communities (those that desire more secure Federated SSO) will have to develop this.

Implementation Steps

1. Update Shibboleth IDP to generate subject confirmation elements in accordance with the HoK Profile (~2 months of developer time)
2. Update Shibboleth SP to validate subject confirmation elements in accordance with the HoK Profile (~2 months of developer time)
3. Update openssl and mod_ssl as appropriate to support Anonymous Client Certificate Authentication (~1 month of developer time).
4. Testing and Analysis, hopefully getting variety of user feedback on different browsers handling of anonymous client certificate use (~2 months of time)
5. Document results and planning for production quality implementations (~2 months of time).

There is likely more to accomplish after the above has been accomplished, but it cannot be adequately predicated without the completion of the above. Depending on browser behavior, the most important next step might be developing browser tooling to make this easier to use. If browsers handle it well, the next type might be turning the Shibboleth prototype into production caliber code. If there were serious changes to openssl or mod_ssl, then they may be the highest priority to get those changes submitted to those opensource projects for inclusion in a future production release.