Re: [GNU Crypto] exception on multiple SaslConnection.send() calls

[Jim Basney]

>From my testing, I believe the fix for this problem is to remove the
call to reset() in gnu.crypto.assembly.Assembly.lastUpdate(byte[], int,
int), to push the wrap operation through the Assembly, flushing internal
buffers so the message is completely wrapped, without resetting the
Assembly, so additional messages can be pushed through subsequently.

When the call to reset() is removed, I can make multiple
SaslClient.wrap() calls using the same SASL context (as it should be).
I used the attached program for testing.

Could this fix be included in the next gnu-crypto release?

SaslTest.java
Description: Text Data

Bryan Hoover <address@hidden> wrote:
> Jim Basney wrote:
> 
> > Bryan Hoover <address@hidden> wrote:
> > > Jim Basney wrote:
> > >
> > > > Bryan Hoover <address@hidden> wrote:
> > > > > Jim Basney wrote:
> > > > > > Am I doing something wrong?
> > > > >
> > > > > Don't comment the reconnect call :).  If possible, the existing 
> > > > > connection will be reused,
> > > > > so "reconnect" is in a sense, a bit of a misnomer.
> > > >
> > > > Hmmm.  SaslConnection.reconnect() calls disconnect() then connect(),
> > > > which creates a new Socket().  Watching the network with ngrep, I see a
> > > > new TCP socket connection after the SaslConnection.reconnect() call.
> > >
> > > Well, statelessness protocals, and all that you know.
> > >
> > > But the security session -- that's the time consuming thing you want to 
> > > reuse if possible, and
> > > that what the lib does, unless, for instance, it's been to long, and 
> > > session timed out.  Then
> > > you have to renogotiate the security layer -- basically start all over 
> > > like a first time
> > > connection.
> >
> > You're saying that I can only call SaslClient.wrap() once, after which I
> > have to go through the SaslClient.evaluateChallenge() loop again?
> 
> I don't know.
> 
> My experience with the routines, and the protocol really, is limited. I 
> helped in making passwords
> immutible, and have used the routines for stateless authentication -- 
> connect, and subsequent
> connection with a new socket, with the subsequent connection(s) resulting in 
> security session reuse.
> 
> BTW, if you go back through evaluateChallenge, the call should not result in 
> renegotiation, but
> rather, reuse of the preexisting security context.
> 
> Assuming you haven't already done it, you might want to google on 'sasl srp 
> protocol', and read up
> on the ins, and outs of that.
> 
> Bryan
> 
> > -Jim