axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Clement <nathan.a.clem...@hotmail.com>
Subject RE: Rampart: UsernameToken with stale timestamps
Date Mon, 18 Mar 2013 04:56:40 GMT
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: ruchith.fernando@gmail.com
> To: java-dev@axis.apache.org
> 
> Hi Nathan,
> 
> Please create a JIRA and attach the patch.
> 
> Thanks,
> Ruchith
> 
> On Wed, Mar 6, 2013 at 7:56 PM, Nathan Clement
> <nathan.a.clement@hotmail.com> 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: nathan.a.clement@hotmail.com
> > To: java-dev@axis.apache.org
> > 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: ruchith.fernando@gmail.com
> >> To: java-dev@axis.apache.org
> >>
> >> 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
> >> <nathan.a.clement@hotmail.com> 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: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-dev-help@axis.apache.org
> 
> 
> 
> -- 
> http://ruchith.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
> 
 		 	   		  
Mime
View raw message