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

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

>It is not my intention to browbeat you on this point. (everybody stop
>laughing) As I said orginally, I don't object to this element, but I
want
>to make sure I know how it should be used to defeat attacks. This
requires
>knowing what the attacks are. Documents like the core specification are
>about generalization and extensibility. Security considerations has to
be
>about nitty gritty details.

I understand. I guess what I'm trying to do is suggest that there's at
least the possibility of future bindings, and future SAML protocol
definitions over those bindings (the extensibility you mentioned), which
are more vulnerable to this. It's admittedly hard to argue specific
details in that light.

I didn't see any compelling reason that it would cause anyone an
implementation problem if it was optionally there, but making it
optional and ignorable isn't really much different from an application
extending Request or whatever later to add it if an occasion arises
where it's useful or necessary.

Of course, I suppose the same could be said for RequestID. I can't think
of any specific use for the matching of RequestID and InResponseTo in
the current SOAP binding or what attack that defeats. Maybe I'm missing
one? If not, presumably it's there for future use as well?

-- Scott