> >The attack described in section 3.4 of the document you reference is
> >based on two assumptions
>
> >1) The client does not verify certificate chains all the way to a
> >trusted CA (in the example attack the malicious party presents a
> >self-signed bogus certificate)
>
> The "client" is unfortunately a *human* that just gets a
> hint that something
> is not correct but he/she may click "Continue" to ignore.
> And maybe even select to
> trust the next time. This is the problem with ad-hoc PKI as
> Dug correctly points
> out. This is also probably the weakest spot in SAML,
> assuming that servers
> are not too easy to hack into.
Your argument here amounts to: "The system may notice that the signature
is wrong, and tell the user, but the user might ignore that warning". I
can't argue with this, but I don't think it's a relevant point. It's the
equivalent to arguing that the waiter might not notice (or might not
care) that I signed "Bob Villa" on my credit card slip.
> >2) The server does not require a verified client certificate.
>
> This is by far the most likely use-case for SAML SSO-scenarious as far
> as I know, assuming the server is the target server in SSO.
>
> Personal opinion: Client-certs in inter-organization
> activities like extranet
> authentication will due to SAML et. al. never be of any significance!
>
In every case where there is a threat that can be attenuated by
bilateral authentication, we point this out in the document. It is
further explained that for session-based systems this means client
certificates are required. If people choose it ignore that, then they
are making an informed choice and are opening themselves to the
risks--risks that are outlined in the document. The purpose of the
document is to allow people to make informed choices.
Personal opinion: B2B web services will drive certificate systems
forward because serious businesses won't play games with security, and
individuals will follow in the wake.
C.
