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

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

>The more important issue is the security considerations. You have
claimed
>that there are threats to the SOAP binding, (or perhaps you had in mind
>some other binding or profile) due to replay, other than denial of
service.

I'll be as direct as I can. The current SOAP binding that is expected to
be in SAML 1.0 is *not* subject to a replay attack. What I claim is that
other, obvious, potential SAML bindings *will* be subject to replay
attacks unless they add a timestamp on their own behalf (by extending
the schema or some other means).

>The current document says this is not the case. You should publish the
>attack so we can include it in security considerations.

You have a request format that is not timestamped. The obvious
implication is that a plaintext signed request can be stolen and
replayed if the binding in use permits the act of signing to be used
alone to authenticate and insure the integrity of the request.

The SOAP binding does not permit this, because it requires that message
integrity be provided by SSL, therefore there's no such attack.

An example future binding that *would* be subject to this attack is one
in which requests are signed, with or without encryption, and sent over
HTTP or some other open protocol, such as SMTP. The request is
authenticated solely by the signature and the message integrity comes
from the same signature.

If you want to rule out such bindings, that's fine. I don't see why
you'd want to do that, but that's the sole motivation I had for saying
anything about it.

>I object to adding potentially complex bells and whistles on "general
>principles." (Based on my experience, any algorithm involving either
>caching or time comparisons is potentially complex, and this involces
>both.) How can somebody design a correct algorithm if we don't identify
>the attacks we are trying to prevent?

I'm hardly going to dispute that building a replay cache isn't more
complex than not building one. Note that there's already one in SAML
(see the Browser POST profile).

But as for the implications? If you don't want to ever support any
bindings that would require one, then there's a simple answer. Just
ignore the IssueInstant utterly, and it won't cost you a thing apart
from a line of code to create it. Voila, no replay cache.

Personally, I think having IssueInstant baked in for people that might
want to support such a binding without having to extend the schema is
worth that line of code, but YMMV.

-- Scott