On May 1,  4:32am, Dick Davies wrote:
} Subject: Re: Centralized User and Password Management
} * John Nemeth <jnemeth@victoria.tc.ca> [1229 09:29]:
} 
} > } of the powerful features of Kerberos is ticket forwarding. It requires
} > } the client application understand Kerberos (or GSSAPI) well enough to
} > } actually forward the cached credentials rather than a username &
} > 
} >      Hmm, yes I see the problem.  Kerberos doesn't really fit into the
} > traditional UNIX way of doing things.  It seems that we need a new
} > protocol independent and method independent client/server
} > authentication protocol, where a server can tell a client what it wants
} > (i.e. prompt user for username and password, send Kerberos ticket,
} > etc.).
} 
} SASL is supposed to address these issues - unfortunately It's horribly
} complex.

     I'm only familiar with using SASL for authenticated SMTP.  I see
that it supports Kerberos and all sorts of other things.  However, I'm
only using the username/password methods in order to be compatible with
the other services being offered.  With authenticated SMTP, the server
lists the methods it can use, then the client indicates that it wishes
to do authentication and the method it wants to use.  After that the
server asks the client for the appropriate information and the client
provides it.

     Does the SASL Kerberos methods use tickets in the appropriate
way?  Can the server drive the authentication in the way that PAM
modules can?  To me, it looks like the server is somewhat passive.  Is
SASL accepted by the industry as a whole?

}-- End of excerpt from Dick Davies