On Tue, Aug 10, 2004 at 10:47:17AM -0300, Markus Moeller wrote:
> Andreas,
>
> how does this translate to GSSAPI sasl mechanism ? Does it depend on the
> implementation or is there any clarification ?
The RFC requires it also.
http://www.ietf.org/rfc/rfc2078.txt?number=2078
It's also a calle
On Tue, Aug 10, 2004 at 09:41:32AM -0300, Andreas wrote:
> Sorry for the binary blurb at the end.
Which got stripped off.
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Nikola Milutinovic wrote:
This is a cross-post to Cyrus INFO list. The question raised here is
whether GSS-API and *-MD5 SASL mechanisms secure the entire
communication, not just the authentication phase, thus making SSL/TLS
unnecessary.
Both GSSAPI (Kerberos 5) and DIGEST-MD5 have the ability t
On Tue, Aug 10, 2004 at 01:17:38PM +0200, Markus Moeller wrote:
> Nikola,
>
> I think you are right, SASL only protects the authentication exchange. I found also
> that cysus-sasl hard codes SSF 56 for GSSAPI.
Check out RFC 2831, section 2.3: (http://www.ietf.org/rfc/rfc2831.txt?number=2831)
On Tue, Aug 10, 2004 at 10:54:27AM +0200, Nikola Milutinovic wrote:
> >>SASL SSF: 56 <-- encrypted channel (only 56 bits though)
>
> No. It simply means that authentication type is of SSF (Security
> Strength Factor) 56. I'm not sure if the SSF has anything to do with
> number of bits u
This is a cross-post to Cyrus INFO list. The question raised here is
whether GSS-API and *-MD5 SASL mechanisms secure the entire
communication, not just the authentication phase, thus making SSL/TLS
unnecessary.
Tarjei Huse wrote:
?? I didn't know , sorry. Please tell me more on how I can use G
