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

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

The counter argument would be that this would require the services and
clients to have access to trusted time.

At the very least we need to create new error codes

RequestTimeOut
RequestInFuture

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----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 3.3.1.2 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>
>

Phillip Hallam-Baker (E-mail).vcf