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

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [security-services] Suggest adding IssueInstant attribute toR equest and Response

 
> 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.

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.)

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?

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.

> 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.

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.

Hal