"Are you the Key Master"

Be a Ghostbuster

In this post after previously looking at other confirmation methods, we’ll be looking at the details of the holder-of-key confirmation method. 

Holder-Of-Key

SAML has the option for a confirmation method called holder-of-key, which is represented by the attribute urn:oasis:names:tc:SAML:2.0:cm:holder-of-key to signify that the subject of the assertion is identified by being the holder of a specific private key. How this work? The holder-of-key confirmation is based on the properties of public-key cryptography. In this case, the original subject signs a small piece of arbitrary data and includes his or her public key with the signed blob. Then, if the receiver trusts the association between this public key and the subject name, they are guaranteed that the original subject is authenticated based on the fact that only they are holder of this private key. This of course is subject to the constraints implicit in the strength of the public-key algorithm chosen as well as the implicit guarantee that only one subject has access to the private key, which is a core assumption built around the public-key infrastructure model. Another assumption has to hold here as well, which is that the receiver has enough information to verify that the public key is trusted and actually associated with the name given to the subject.

This association can be an implicit, stored assumption by the receiver or based on an X.509 certificate model, which would also require the receiver to do additional trust processing. It is often said that this model is the "most secure" confirmation method. In one sense, this is correct because the authenticity of the subject rests on a digital signature created by the subject, over and above the claims of the issuer. Remember, subject re-confirmation is just that - reconfirmation of the issuer's original claim that the subject is authenticated. One might argue that if the holder-of-key data is trusted, the weakest link in the chain of authentication is the issuer's assertion regarding the subject - after all, the subject is effectively authenticated with her or her own digital signature. The obvious downside of this method is that the original subject must perform a digital signature and have access to a private key, which pulls in assumptions regarding entity key issuance, revocation and management, which may be an unnecessary trade-off for security and complexity.

Next: Looking at AWS