From: Howard Chu (hyc at highlandsun dot com)
Date: Thu Mar 25 2004 - 16:02:48 EST
> -----Original Message-----
> From: owner-cyrus-sasl at lists dot andrew dot cmu dot edu
> [mailto:owner-cyrus-sasl at lists dot andrew dot cmu dot edu]On Behalf Of Rob
> Siemborski
> Sent: Thursday, March 25, 2004 8:56 AM
> To: Jeremy Rumpf
> Cc: Igor Brezac; Roman Medina; cyrus-sasl at lists dot andrew dot cmu dot edu
> Subject: Re: saslauthd + pam_mysql broken ?
>
>
> On Thu, 25 Mar 2004, Jeremy Rumpf wrote:
>
> > > In my opinion, sasl lib should not alter the username to
> begin with;
> > > user at domain dot tld is a perfectly valid userid. In addition
> non of the
> > > plaintexts mech have use for the realm value like gssapi
> and digest-md5
> > > mechs do.
> > >
> >
> > I agree as well. At this point it seems odd to have sasl
> split foo at bar dot com up
> > into username/realm components and then have auth_pam
> reassemble them, but if
> > that is the best compromise it seems sensible.
>
> It is unfortuinately necessary, as some saslauthd mechanisms treat the
> realm differently than just appending it.
re: your last comments to Bugzilla ID 2326:
>I believe this is compliant with the specification, even if it means that
the
>realm= parameter ot the digest-response (and digest-challenge) is basicly
>useless. This makes DIGEST-MD5 consistant with every other mechanism (yes,
>KERBEROS_V4 and GSSAPI have a slightly different concept, but the execution
in
>this case is the same -- split at the @ sign). It also allows *all*
mechanims
>to support realms.
Rendering the DIGEST-MD5 "realm" parameter useless does not seem like a
positive thing to do. If it is truly useless, it shouldn't have been in the
spec. Since it is in the spec, there is probably an implementation out there
that depends on using it, and Cyrus' behavior will interfere with
interoperability in that case.
>I certainly do NOT agree that we should change how realms are handled in the
>mechanisms that do not internally support realms. And I don't agree that we
>should handle DIGEST differently from the rest (someone else is free to
write a
>3rd party plugin to do that).
>Now, I *could* understand an argument that we shouldn't be doing *anything*
>about realms in the processing of the identifier, and instead just passing
the
>identifier back to the calling application wholesale (and, again, in
>DIGEST-MD5's case, advertising and accepting only one realm). I don't see
this
>behavior changing outside of a minor version bump though (and I'm not really
in
>love with it anyway).
This sounds to me like the best solution. Ultimately the calling application
is the one that most knows how an identity is going to be used. The SASL
library should just be transparent here, and pass the name the user provided
verbatim. Again, since the specs don't mention using realms in most of these
mechs, it isn't right for the SASL library to presume their usage. It is fine
for an application to parse and use realms if it wishes.
>I can also understand an argument that we should be disallowing user_realm
>values with an '@' sign.
And this also contradicts the spec that explicitly states that '@' is a valid
character in a realm name. Once again, taking this position will break
interoperability.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
|
|
|