[keycloak-dev] Support for key rotation in SAML Redirect binding

[John Dennis]

On 11/01/2016 11:49 AM, Hynek Mlnarik wrote:
>     6) My comment about instances sharing keys (actually keyID's) was in
>     reference to the fact *both* parties have to know the keyID so you
>     need a mechanism to share that information, the entity metadata is
>     the best mechanism, but you could also do it via some out of band
>     mechanism.
>
>
> Which out of band mechanism you mean? I am not aware of any standard one.

By out of band I mean a non-standard exchange of information, not back 
channel. So yes, the only standard way I know is via metadata.


>     8) I believe adding the keyID as an additional query parameter for
>     HTTP-Redirect is the easiest and cleanest solution. SAML does not
>     prohibit additional query parameters. Query parameters are
>     consistent with the rest of the HTTP-Redirect binding. Of course one
>     has to be careful concerning the total URL length. Of course you
>     could also use a different binding as per item 3 because this is a
>     KC to KC case.
>
>
> Key ID in query parameter (or any additional query parameter) in the
> parameter would not protected by the signature, only
> SAMLRequest/SAMLResponse, RelayState, and SigAlg are. Including it in
> SAML protocol message has hence benefit in Key ID protection.

The recommendation is such messages be exchanged over a secure transport 
such as TLS, since this is an HTTP-Redirect binding that means HTTPS. 
That means all the query parameters are pretty safe. Even if the keyID 
were modified by a nefarious actor what would the practical consequences 
be? I suppose that might depend on how strict your implementation is, 
here is the basic choices as I see them:

1) keyID lookup fails, you fail the protocol exchange.

2) keyID lookup succeeds but fails to validate signature. You fail the 
protocol exchange.

However if either of the two above cases occur you could be more 
forgiving and treat it as if no keyID had been passed and fall back to 
iterating over the keys bound to the entity, something you have to 
implement anyway because the keyID will often be absent.

The xmlSig spec is silent on what happens if the keyID (actually the 
KeyName) does not produce a known key. It does not specify if one may 
fallback to application specific context or not.

I personally feel it's OK to use application specific context, if one 
accepts that then the keyID if present becomes a hint not a mandate.

In summary, I don't see tampering with the keyID a significant risk over 
HTTPS or if it's treated only as a hint a serious problem that could be 
used to compromise the communication.

-- 
John