Thread: [Beepcore-java-users] SASL Interoperability

And finally ( :-) ):
 
I've been using the Java beepcore implementation against the C beepcore
implementation (or more properly with the Cyrus SASL libraries) and come
across a couple of interoperability issues.
 
The first was with the base64 encoding of <blob>s. The Java SASL
libraries split the encoding across multiple lines - the Cyrus SASL
libraries expect it all to be on one line. At first, I though that
RFC3080 was vague on this issue, but it does say in its examples that
although the text is split across multiple lines, in actuality, the blob
wouldn't be. However, it is read we would increase interoperability if
we *didn't* split across multiple lines.
 
The second is really a problem with the Cyrus libraries, but I'll
include it here in case anyone reading can influence the Cyrus group.
RFC2831 (SASL/DIGESTMD5) states that 'qop-options' is optional and
defaults to "auth" if not specified. Cyrus simply aborts the exchange if
it isn't specified.
 
Thanks - Paul.

On Thu, 2003-05-29 at 09:10, Paul Andrews wrote:
> And finally ( :-) ):
>  
> I've been using the Java beepcore implementation against the C
> beepcore implementation (or more properly with the Cyrus SASL
> libraries) and come across a couple of interoperability issues.
>  
> The first was with the base64 encoding of <blob>s. The Java SASL
> libraries split the encoding across multiple lines - the Cyrus SASL
> libraries expect it all to be on one line. At first, I though that
> RFC3080 was vague on this issue, but it does say in its examples that
> although the text is split across multiple lines, in actuality, the
> blob wouldn't be. However, it is read we would increase
> interoperability if we *didn't* split across multiple lines.

I agree this should be fixed in beepcore-j. I'm currently refactoring
the tuning reset code so I won't be able to get to this for a few days.
If you need it sooner and would like to submit a patch I'm happy to
check it in.

> The second is really a problem with the Cyrus libraries, but I'll
> include it here in case anyone reading can influence the Cyrus group.
> RFC2831 (SASL/DIGESTMD5) states that 'qop-options' is optional and
> defaults to "auth" if not specified. Cyrus simply aborts the exchange
> if it isn't specified.

I don't know much about SASL but is there something that could be
changed in beepcore-j to make this work?

--Huston

> -----Original Message-----
> From: bee...@li... 
> [mailto:bee...@li...] On 
> Behalf Of Huston
> Sent: Thursday, May 29, 2003 11:55 AM
> To: Paul Andrews
> Cc: Bee...@li...
> Subject: Re: [Beepcore-java-users] SASL Interoperability
> 
> 
> On Thu, 2003-05-29 at 09:10, Paul Andrews wrote:
> > And finally ( :-) ):
> >  
> > I've been using the Java beepcore implementation against the C
> > beepcore implementation (or more properly with the Cyrus SASL
> > libraries) and come across a couple of interoperability issues.
> >  
> > The first was with the base64 encoding of <blob>s. The Java SASL
> > libraries split the encoding across multiple lines - the Cyrus SASL
> > libraries expect it all to be on one line. At first, I though that
> > RFC3080 was vague on this issue, but it does say in its 
> examples that
> > although the text is split across multiple lines, in actuality, the
> > blob wouldn't be. However, it is read we would increase
> > interoperability if we *didn't* split across multiple lines.
> 
> I agree this should be fixed in beepcore-j. I'm currently refactoring
> the tuning reset code so I won't be able to get to this for a 
> few days.
> If you need it sooner and would like to submit a patch I'm happy to
> check it in.

No hurry - we modified the Cyrus side instead for the time being. Fixing
it in the Java classes would require using a different base64 encoder
than the Sun one - there are plenty around, but I didn't want to modify
the beepcore-j code so I don't have a patch to provide. Sorry.

> 
> > The second is really a problem with the Cyrus libraries, but I'll
> > include it here in case anyone reading can influence the 
> Cyrus group.
> > RFC2831 (SASL/DIGESTMD5) states that 'qop-options' is optional and
> > defaults to "auth" if not specified. Cyrus simply aborts 
> the exchange
> > if it isn't specified.
> 
> I don't know much about SASL but is there something that could be
> changed in beepcore-j to make this work?

No. beepcore-j doesn't do DIGESTMD5 at all - it is in my implementation,
so, once again, we fixed it in our version of the Cyrus libraries. It
really needs to be fixed by the Cyrus team so we'll probably be in touch
with them :-).

It would be good to submit our DIGESTMD5 code to beepcore. We'll have to
work on our management for that, plus it uses a preview release of Sun's
SASL API for the initiator side and I've got a few issues with that too
:-). I wrote the listener side myself.

> 
> --Huston
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Beepcore-java-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-java-users
>