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

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

>Sure you can intercept and keep the message, but if the channel
requires
>authentication, you can't SEND it unless you can authenticate.

I don't think it's the case that all future useful bindings of SAML will
require an authenticated channel apart from the messages themselves.
Maybe I'm wrong (well, I definitely am currently, since I can't build
one without being vulnerable to replay, so I wouldn't).

>Well the section of the document in question clearly says that denial
of
>service is the threat. If that is wrong, we should fix the document.

The section on Replay (5.3.1.2) is in the section on the SOAP binding,
which is a specific binding that as currently written, is not vulnerable
to replay because message integrity MUST happen using SSL. Chris notes
that other schemes for integrity would be vulnerable. Where you put that
is an editorial issue, I guess.

>In my opinion, this is only a threat when using certain types of
>SubjectConfirmation. I don't think this is an issue in the context of
the
>SOAP binding, however I have not analized it carefully.

The requirements for the SOAP binding do not mandate use of SSL, but
they do mandate using SSL if you want message integrity (which obviously
is required if you're going to fix anything with a timestamp).

I'm not claiming SAML as written is broken, I'm just saying by leaving
out a minor, ignorable attribute, it's constraining on future bindings,
overly so IMHO. Sorry if I was giving the wrong impression.

-- Scott