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

Title: RE: [security-services] Suggest adding IssueInstant attribute to Request and Response

I don't really object to making this change, but I would like to make a couple of points.

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 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. On the requestor side, I would assume that any response received when there is no pending request would be quickly discarded.

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.


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, January 08, 2002 12:31 PM
> To: SAML
> Subject: [security-services] Suggest adding IssueInstant attribute to
> Request and Response
> Referencing section of the security considerations
> document, it
> notes that unless the transport layer (eg. SSL) prevents the
> capture of
> request messages, the use of XML signing and/or encryption does not
> prevent an attacker from capturing messages and replaying them.
> This is fairly obvious, but instead of leaving the problem,
> why not just
> solve it by providing a means to build a bounded replay cache
> in clients
> and servers?
> I propose adding the IssueInstant attribute (found currently in
> Assertion) to both Request and Response. This is a trivial
> change, adds
> no overhead, and provides the means to timestamp a request or response
> message in a uniform, secure way (via signing) for any
> bindings that may
> come along. The obvious initial issue is use of SOAP with signing but
> without SSL, which I believe is specified as optional in bindings-07.
> Proposed schema change:
> In RequestAbstractType and ResponseAbstractType, add:
>       <attribute name="IssueInstant" type="dateTime" use="required"/>
> It could be optional, but it seems simpler to me to just
> expect it. Text
> should be minimal. I would propose not specifying policy on message
> lifetime in bindings and let the endpoints decide.
> -- Scott
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC