Thanks Nathan. - Ruchith
On Mon, Mar 18, 2013 at 12:56 AM, Nathan Clement <[email protected]> wrote: > Hi, > > I created https://issues.apache.org/jira/browse/RAMPART-401 for this > > Thanks, > > Nathan > >> Date: Sun, 17 Mar 2013 13:23:36 -0400 > >> Subject: Re: Rampart: UsernameToken with stale timestamps >> From: [email protected] >> To: [email protected] >> >> Hi Nathan, >> >> Please create a JIRA and attach the patch. >> >> Thanks, >> Ruchith >> >> On Wed, Mar 6, 2013 at 7:56 PM, Nathan Clement >> <[email protected]> wrote: >> > Hi, >> > >> > I've attached the patch against trunk that shows what I'm talking about >> > here. Should I raise a JIRA issue for this, or would you want to >> > implement >> > it differently? >> > >> > Thanks, >> > >> > Nathan >> > >> > ________________________________ >> > From: [email protected] >> > To: [email protected] >> > Subject: RE: Rampart: UsernameToken with stale timestamps >> > Date: Wed, 6 Mar 2013 11:54:43 +1100 >> > >> > >> > Hi, >> > >> > Thanks for your responses. I'm aware of the Timestamp element in the >> > wsse:Security header, however my understanding is that it's only of >> > value if >> > it is signed (the blog post below confirms this). In the case where only >> > a >> > UsernameToken is provided and no signing is done, the Timestamp element >> > doesn't stop replay attacks since an attacker could just change the >> > Timestamp value freely. >> > >> > The UsernameToken profile gets around this problem by using a >> > PasswordDigest >> > along with the Created element in the UsernameToken. The Created >> > timestamp >> > is included in the digest with the password, which effectively makes the >> > PasswordDigest a MAC on the UsernameToken element. An attacker cannot >> > change the Created timestamp without knowing the password because the >> > PasswordDigest would be incorrect. Therefore, I think that Rampart >> > should >> > perform the same validation on UsernameToken/Created as it does on the >> > Timestamp. I'm happy to experiment with a patch to >> > PolicyBasedResultsValidator to implement this. >> > >> > Note that I'm still new to WS-Security, so please feel free to correct >> > me if >> > my understanding is wrong. >> > >> > Thanks, >> > >> > Nathan >> > >> >> Date: Tue, 5 Mar 2013 11:14:55 -0500 >> >> Subject: Re: Rampart: UsernameToken with stale timestamps >> >> From: [email protected] >> >> To: [email protected] >> >> >> >> Hi Nathan, >> >> >> >> I believe we already have this in Rampart. >> >> Please see: >> >> http://hasini-gunasinghe.blogspot.com.au/2012_02_01_archive.html >> >> >> >> Thanks, >> >> Ruchith >> >> >> >> On Tue, Mar 5, 2013 at 1:22 AM, Nathan Clement >> >> <[email protected]> wrote: >> >> > Hi, >> >> > >> >> > I was wondering if there is any code in Rampart (or WSS4J) that >> >> > rejects >> >> > stale timestamps in UsernameToken elements? The WS-Security >> >> > UsernameToken >> >> > Profile says the following: >> >> > >> >> > It is RECOMMENDED that web service producers provide a timestamp >> >> > “freshness” >> >> > limitation, and that any UsernameToken with “stale” timestamps be >> >> > rejected. >> >> > As a guideline, a value of five minutes can be used as a minimum to >> >> > detect, >> >> > and thus reject, replays. >> >> > >> >> > >> >> > If there's nothing existing to implement this recommendation, I can >> >> > write a >> >> > patch to implement this. I thought this could be done in >> >> > RampartEngine >> >> > after the "nonceLifeTimeInSeconds" is checked. I could use the same >> >> > timeout >> >> > period and reject any request with a Created timestamp older that >> >> > this >> >> > value. Is that the best place to implement this feature? >> >> > >> >> > Thanks, >> >> > >> >> > Nathan >> >> >> >> >> >> >> >> -- >> >> http://ruchith.org >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> >> >> -- >> http://ruchith.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> -- http://ruchith.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
