11:46 a.m.
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