RE: [security-services] Suggest adding IssueInstant attribute toRequest and Response

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

>This is a good start, but for a replay attack, there has to be some
>semantic difference between the original and the replayed version. For
>example, an idempotent request is immune to a replay attack. (Except
DOS
>which you have excluded.)

My technical language is probably not accurate. I should say
"impersonation", perhaps?

>Let's consder the cases separately. 
>Request: Not clear what kind of attack is possible by repeating
yesterday's >request. What do you have in mind? 

I can steal Alice's request for attributes (the most likely case, and
the only one Shibboleth would be concerned with). If I can replay it
successfully immediately or in the future, I can get attributes that
only Alice might be allowed to see (or at least that I'm not allowed to
see). I let her request go on through as well, so she never knows, since
she gets her answer.

The current SOAP binding prevents this, because Alice has to
authenticate with her client cert (she could use basic-auth, but without
any integrity the timestamp won't help, so I'm assuming SSL).

A straight signed request over HTTP or SMTP (or BXXP, etc.) will be
vulnerable to this.

You can easily say, "Then don't use such a binding." or that the binding
better add enough machinery to fix the problem. I'd agree, except that I
would think there'd need to be at least some good argument for that, and
having to ignore a timestamp that you don't care about using in your
Attribute Authority because you only care about SSL doesn't seem like a
very good one to me.

>Response: Here the attack might be to obtain an ATTR ASSn containing
values
>that had been administratively changed. Ditto for AuthZ Dec ASSN.
However,
>these have validity date/time fields already. Doesn't work for AUTHN
ASSN
>because it has time of AUTHN.

Right. It's not an issue with responses, since I can't steal a response
and do anything with it other than give it to somebody that shouldn't
have it. That's an encryption requirement and has nothing to do with
timestamps.

>I repeat, we should either define the attack (preferable) or the
algorithm,
>so as to demonstrate that the added fields are both necessary and
>sufficient to defeat it. Lots of other requests for added fields in
SAML
>have  been voted down because the group opinion was they added more
>complexity than value.

I understand (although here I fail to see any complexity whatsoever for
people not interested in such bindings as may be vulnerable).

Is the threat at least clear now?

-- Scott