On 10/3/12 10:05 AM, "Sam Hartman" <[log in to unmask]> wrote:
>
>My personal opinion is that if we do end up with such mechanisms,
>openssh should only accept no-integrity mechanisms known not to suffer
>from that defect. saml-ec is not such a mechanism today because it
>never supports integrity. We need to be careful adding integrity if we
>want to avoid turning it into such a mechanism. (Using a different OID
>is not good enough unless that's protected).
My intention is that since it's no great burden for the client mechanism
code to do integrity if the IdP supplies the key, the mechanism should
always supply integrity and should fail otherwise. There's spec work to do
around encryption types I suspect, but as a starting point, I think I'm on
the right path now.
That doesn't speak to your overall point, but it shouldn't be an issue for
SAML-EC in its final form.
Note that the actual establishment of the context is still often going to
be bearer-based at the initial step. But if that's an issue, the server
can require holder of key, and there's no bid-down possible there, it's
determined by the IdP and the "real client" and an attacker can't change
that after the fact.
-- Scott
|