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

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

>First, what the security considerations document actually says in
3.3.1.2
>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
authenticated
>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
there
>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
there.

>While it is true that XML encryption will not prevent replay, SAML does
not
>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