ietf-nntp Re: WG Review: Simple Authentication and Security Layer (sasl)

[Ken Murchison]

Andrew Gierth wrote:
> 
> >>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:
> 
>  Ken> Since what is being worked on in this group is a SASL profile,
>  Ken> it will not be added to the SASL WG charter.  I'm sure that
>  Ken> members of the SASL WG will be happy to review the NNTP SASL
>  Ken> profile document (I for one, as well as Larry Greenfield and Rob
>  Ken> Siemborski).  In fact, Rob and I have already had an extensive
>  Ken> email thread with Jeff on the NNTP SASL stuff.
> 
> The basic problem I still have with SASL (or indeed any of the secure
> auth schemes I've seen) is that I've yet to see a solution to the
> problem of handling multiple external authentication domains.
> 
> Specifically:
> 
> suppose there are a number (>1) of authentication servers A1, A2,
> etc., which are accessible via potentially different protocols
> (e.g. RADIUS or something similar), and are not under my control. I
> get a connection from a user, and based on the username that they
> supply, I have to query a specific one of the authentication servers
> in order to decide whether to admit the user.
> 
> As far as I can tell that requires being able to recover the password
> at the server end of the exchange, something that all the SASL schemes
> I've seen go to great lengths to prevent. Note that using TLS is not
> an option unless it can be confined to the auth exchange only; the
> overhead of doing encrypted connections is infeasible in my environment.
> 
> This problem _ought_ to be solvable, but I don't have the experience in
> crypto design to do it myself.


Unless I don't fully understand your problem, I don't see what this has
to do with SASL.  SASL and the associated mechs describe a standardized
over-the-write format, not how the user is actually authenticated.  It
seems to me that this should be solved within the server
implementation.  For instance:

- use a fully qualified username (foo at example.com) which specifies the
auth domain

- use PAM to layer the authentication methods

- use an LDAP lookup to direct the query to the correct auth server

- use DIGEST-MD5 in which the server can present a list of realms for
the client to choose from


Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp