Open
Bug 133939
Opened 22 years ago
Updated 8 months ago
[RFE] SOCKS: cannot use kerberos v5 (GSS-API) authentication with
Categories
(Core :: Networking, enhancement, P5)
Core
Networking
Tracking
()
NEW
Future
People
(Reporter: peter.lees, Unassigned)
References
()
Details
(Keywords: helpwanted, Whiteboard: [necko-would-take][proxy])
the SOCKS5 proxy support in mozilla does not, currently, support Kerberos v5 (GSS-API) authentication/authorisation. the work-around usable in netscape 4.x and other browsers (eg opera, lynx) is to interpose the GSS-API-enabled libsocks5_sh shared object using (on solaris) LD_PRELOAD. this work-around *does not work* with mozilla, hence i am submitting this as a bug, rather than an enhancement request. the impact is that mozilla cannot participate in single-sign-on environments which use Kerberos v5 as the authentication/authorisation mechanism. considering MS Active Directory uses what is essentially Kerberos v5, this kind of authentication mechanism will inevitably become more widespread. completing the SOCKS5 proxy implementation to include GSS-API support will help mozilla keep pace, as well as restoring functionality to existing users of netscape 4.x.
Reporter | ||
Comment 1•22 years ago
|
||
RFC1928 describes SOCKS5 RFC1961 describes GSS-API for SOCKS 5 nb - according to RFC1928: Compliant implementations MUST support GSSAPI and SHOULD support USERNAME/PASSWORD authentication methods. (mozilla reverses this - user/pass is implemented, gssapi is not...)
Temporarily "futuring" all PAC&SOCKS bugs to clear new-networking queue. I will review later. (I promise) If you object, and can make a case for a mozilla 1.0 fix, please reset milestone to "--" or email me.
Target Milestone: --- → Future
I'm almost certain this isn't implemented, so RFE.
Severity: minor → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Summary: cannot use kerberos v5 (GSS-API) authentication with SOCKS5 proxy → [RFE] SOCKS: cannot use kerberos v5 (GSS-API) authentication with
Reporter | ||
Comment 4•20 years ago
|
||
turns out i was mistaken with my original comment: the only auth mechanism implemented is "NOAUTH" - ie, not even user/pass. *however* i'd like to re-iterate that RFC1928 specifies that "Compliant implementations MUST support GSSAPI and SHOULD support USERNAME/PASSWORD authentication methods." ftp://ftp.rfc-editor.org/in-notes/rfc1928.txt i guess it's a matter of opinion then whether the non-implementation is a bug or a feature/enhancement problem. i wish i knew myself where to start with this, but i don't 8( it appears this bug is becoming a wider issue: bug 122752 and bug 200882 (at least) seem to be related
Updated•14 years ago
|
Assignee: general → nobody
QA Contact: socksqa → networking
Updated•7 years ago
|
Whiteboard: [necko-would-take]
Updated•7 years ago
|
Whiteboard: [necko-would-take] → [necko-would-take][proxy]
Comment 5•6 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Updated•8 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•