InCommon metadata support

["Cantor, Scott" <>]

On 12/7/16, 5:22 PM, 
"
 on behalf of Tom Poage" 
<
 on behalf of 
>
 wrote:

> Assuming this is not an either-or proposition, I'm not sure I understand 
> the problem (wrt risk management) layering in TLS
> here tries to solve.

Metadata in an explicit key trust model is largely about revocation, and the 
validity window of metadata (two weeks in InCommon) is the period during 
which a revoked key can be used. The main attack against explicit key trust 
via metadata is substitution of stale metadata containing revoked keys, and 
the use of TLS mitigates that if the server is authenticated.

The main argument against doing it up until now is the fear that it will 
encourage bad practice and ignoring the signature, and it does, but when the 
risk of substitution attacks rises due to increased frequency of metadata 
access, it's more important to address that threat than to try and blackmail 
implementers into doing things they haven't done anyway. 

That's all aside from the ADFS issue.

> One case I can think of where layering in TLS may help is when the consumer 
> fails to validate the XML signature against
> the independently-obtained signing certificate. And I would hope metadata 
> consumers do not validate by comparing the
> signature against the public key in the XML (my first thought is remove the 
> public key from the XML, but that would seem
> to leave a bootstrapping problem identifying which key encrypted the 
> signature ... unless the consumer is independently
> shown or just knows which cert/key to use. Hmm).

We configure the key to use, if you want to leave it out, that's fine. Or 
just signal it by name. There are a small number of implementations that 
might catch, but one that know how to spell metadata. It might catch a few 
people doing fresh implementations on top of broken SAML code.

> I seem to recall mention in the report of how TLS might help mitigate 
> man-in-the-middle, but don’t recall seeing how so. I
> could guess that if a MiTM intercepts an MDQ response and either strips it 
> of the signature or adds some other signature,
> any “conforming” consumer would detect that and abort.

ADFS is not, and will never be, conforming. If you want it to play, you have 
to do TLS, and if you want it to matter, it needs to be non-commercial, at 
least as an option. If I trust 100 CAs with no discrimination and don't even 
control the list or have the ability to contrain which CA I'm trusting, I 
gain nothing of value. It's actively harmful.

> So does layering in TLS then have tangible benefit reducing risk for 
> metadata consumers, or foster/enable laziness on the
> part of the data consumer? :-)

Both. Sometimes you have to live with it.
    
> Whether TLS uses commercial vs. self-signed, the only difference seems to 
> be a minor difference in effort to establish trust,
> given the typical bundle of known (presumably trusted) CAs on most 
> operating systems.

This is not a minor difference, in large part due to the lack of naming 
constraints in the model. You're trusting every CA for *everything* when you 
follow that model. This is why people who remotely load metadata today are 
often doing it wrong; they think they're loading "SP A's metadata", but that 
channel unless it's constrainted could feed them *anybody's* metadata. 
Whitelisting filters are a form of naming constraint.

> I do see using a self-signed certificate as presenting an obstacle to the 
> typical skill set of vendors I’ve been working with

Then I would submit that people can host their own metadata too, behind any 
CA they want. In fact, if InCommon wants to, there's no reason it couldn't 
host it behind both, or support alternative chains. That would be robust, 
whereas pinning is a time bomb when the certs change.

-- Scott