RE: [saml-dev] SAML V2.0 Holder-of-Key Web Browser SSO Profile not immune against man-in-the-middle attack

["Scott Cantor" <cantor.2@osu.edu>]

> What I meant, by an "official" certificate, was a certificate given by an
> authority in a controlled way, with a real enrollment (with face-to-face
> identity check, for instance).

That's subject to the requirements of the deployment. No certificate
enrollment process is perfect, and in-person proofing isn't always possible.

> Typically, this is a governmental one, a
> company/institution one, a class 3 commercial one, ...
> This was to differentiate with a certificate that does not link to a
> physical user, like a self-issued one, or a self-service one.

What you're saying is that the knowledge of the person/key binding is
"sufficient", and I agree. But that's all you can say. The rest is policy,
ans is subjective. It's a property of this profile that the SP may well care
a great deal about how the IdP associates keys with users, but beyond that,
we really can't say much.

It is possible, of course, to use the AuthnContext to represent much of
this, but in practice, it's usually handled out of band.

> In order to link both, you need, at some point, to use an
> "official" certificate (or a known key) to establish your channel to your
> IdP in order to totally forbid MitM. In a usual Web environment, this
means
> establishing a TLS session with client-side authentication, with your
> "official" certificate.

You should stop at "known key". That's all you can say.

For example, there could be a known key issued through some process that
might result in a certificate, but the user need not use that same
certificate when it authenticates as long as the key is the same.

> Even with opaque DN, etc., anonymity is never ensured. A complete
decoupling
> is better, which also solves the privacy problem you mentioned. So, I
agree
> with you, you should not be obliged to use the same certificate with your
> IdP and your SP.

I agree, but unfortunately browsers are not likely to give you much choice
in the matter unless you force users to juggle muliple certificates and
manually pick the right one to send to each one. A customized client could
of course generate temporary certs and even juggle multiple keys.

> So, if we could use, during the IdP session another protocol establishing
> proof of possession of another key, and use this second key to connect the
> SP, I think we would be both immune against MitM, and privacy friendly.

Unless you have something in mind that is compatible with a browser, I'm not
sure what you're suggesting. A non-browser doesn't require anything
substantially new, since the dialog with the IdP could be enhanced to
include registering additional keys and that kind of thing.

-- Scott