<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The same response multiple times from the browser without the RP being able to set a cookie?<div><br></div><div>Is that really that common a issue?</div><div><br></div><div>One way that could possibly work is if there is an existing session cookie that the RP associates with the response and tracks on the RP end. This has clustering synchronization issues though.</div><div><br></div><div>Artifact resolution won't help for that. </div><div><br></div><div>At the moment several large RP's are only using the timestamp in the nonce to protect against replay, due to clustering issues.</div><div><br></div><div>Only checking the timestamp while better than nothing would not be considered LoA 1 for a RP.</div><div><br></div><div>SP-800-63 is looking for checking a nonce to protect against replay and also would like timestamp checking (not on or after) on bearer tokens., to mitigate against interception at LoA 1. </div><div><br></div><div>The GSA LoA 1 profile required RP to check the nonce for replay and recommends placing a maximum time on the validity of an assertion based on the timestamp in the nonce.</div><div><br></div><div>At LoA 2 timestamp checking would be required.</div><div><br></div><div>I think finding a way for RP to detect and deal with the issue is the way to go rather than changing the protocol.</div><div><br></div><div>John B.</div><div><br></div><div><div><div>On 2010-01-28, at 11:11 AM, Andrew Arnott wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Jan 28, 2010 at 3:16 AM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>The problem is that RP are not tying the received assertion to the browser session the first time they receive the token.</div><div><br></div><div>If you get the same token from the same browser session multiple times that should not be a problem.</div>
<div><br></div><div>If you get the token from a different browser session that is a problem and it should be rejected.</div><div><br></div><div>I don't think nonce processing in the spec is broken. Perhaps RP implementations need to improve there handling of authentication tokens.</div>
<div><br></div><div>eg set a cookie with the nonce from the last authentication so that if the user hits the back button and resubmits you can detect it.</div></div></blockquote><div><br></div><div>The broken scenario I started this thread with is about the RP receiving the assertion multiple times from the browser, but in such a way that the initial HTTP responses were discarded. So the RP setting a cookie in the HTTP response wouldn't help the scenario.</div>
<div><br></div><div>But I think what you're suggesting would definitely help some of the problems around this.</div></div>
</blockquote></div><br></div></body></html>