OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

>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
>to make sure I know how it should be used to defeat attacks. This
>knowing what the attacks are. Documents like the core specification are
>about generalization and extensibility. Security considerations has to
>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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC