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 attributetoRequest and Response

>First, what the security considerations document actually says in
>is that the threat in a SOAP environment is denial of service. Its not
>clear that this is actually a threat. If requests require an
>channel, then only legitimate entities can attack. Conversly, if
>unauthenticated communications are allowed, anybody can create bogus
>requests and keep an AP quite busy wiout having to replay anything.

Can I assume the authenticated channel prevents interception of
requests? Authentication doesn't require this. I don't have to be Alice
to intercept a signed message from Alice sent via HTTP, SMTP, etc. and
save it for next month. The issue is whether that buys me anything. In
S-MIME, maybe it does if Alice was sufficiently vague in her message. In
SAML, it certainly does...I'm Alice for that request. That's replay and
impersonation, not denial of service.

>On the requestor side, I would assume that any response received when
>is no pending request would be quickly discarded.

Yes, which is why even though I think for symmetry Responses should also
carry IssueInstant, I didn't ask for it. I can use InResponseTo to match
it up over an asynch channel as well, so there's no security issue

>While it is true that XML encryption will not prevent replay, SAML does
>currently specify its use. SSL and TLS are currently the only way to
>protect content from being read and they will prevent replay.

I was under the impression SAML specified but did not require its use
(note existence of Signature elements in Request and Response), and I
assumed that was for reasons of practicality (the lack of DSig
libraries) rather than anything more specific. And I'm assuming other
bindings will emerge.

Why make it impractical to ever use an open channel with a signed
request, or complicate future scenarios?

-- Scott

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

Powered by eList eXpress LLC