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

>Sure you can intercept and keep the message, but if the channel
>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
>service is the threat. If that is wrong, we should fix the document.

The section on Replay ( 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
>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

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

Powered by eList eXpress LLC