Signing authN requests: yea or nay?

[Cantor, Scott]

On 9/24/13 5:51 PM, "Erdos, Marlena" <marlena_erdos at harvard.edu> wrote:
>
>Hmm.  While I don't entirely remember the discussions :-), I do remember
>that the original spec only had an artifact being returned as a response
>to the authentication request,  and not potentially interesting
>information about the user.
>Authentication  of the requester definitely got done on the attribute
>request :-).

Only if you use TLS, actually. If you use signatures, then there is no end
to end security and the actual party presenting the request could be
anybody (modulo a freshness check to limit the window). This is the dirty
little secret of message-signing as a substitute for transport
authentication, and it's why protocols that do this kind of thing tend to
assume encryption of application data (e.g., Kerberos).

But you're also talking about back channel.

On the front-channel you lose any pretense of preventing an attacker from
obtaining a valid, fresh signed request essentially at will. There's no
mitigation of giving responses to attackers except for encryption and/or
just not handing out responses to clients that don't authenticate
themselves. In this case meaning the user has to authenticate first. SSO
of course reduces that to a cookie.

This is a different issue from preventing a client from handing a response
to an attacker in the form of a malicious SP, and that mitigation (the
endpoint check) essentially reduces to commercial TLS at the end of the
day, because that's all browsers can do.

If you really, really care about this, then you can not push attributes
and rely on queries like before. But you won't get any non-Shibboleth SPs
to do that with you. I think you'll find that at the end of the day the
data you're sending out just isn't that sensitive in the majority of cases.

But the point I'm making is that signing requests is not going to protect
your data if you're pushing it front-channel. It's not targeted at that
particular threat.

-- Scott