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

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [security-services] Suggest adding IssueInstant attribute toR equest and Response

The more important issue is the security considerations. You have claimed that there are threats to the SOAP binding, (or perhaps you had in mind some other binding or profile) due to replay, other than denial of service. The current document says this is not the case. You should publish the attack so we can include it in security considerations.

I have stated that I think the denial of service attack is NOT defeated by your proposed change, although it does not make things worse in any way.

I object to adding potentially complex bells and whistles on "general principles." (Based on my experience, any algorithm involving either caching or time comparisons is potentially complex, and this involces both.) How can somebody design a correct algorithm if we don't identify the attacks we are trying to prevent?

Hal

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, January 15, 2002 3:33 PM
> To: 'SAML'
> Subject: RE: [security-services] Suggest adding IssueInstant attribute
> toR equest and Response
>
>
> > 1) we add in the attributes as OPTIONAL
> > 2) we note that you should only use them if you believe you actually
> >     know the time.
> > 3) we add error sub codes for 'TooEarly' and 'TooLate'
>
> That's consistent with my thinking. The qualifier in #2 presumably
> applies to lots of other things in SAML, I guess.
>
> -- Scott
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>