[15636] in Kerberos_V5_Development
Re: prompter type question
daemon@ATHENA.MIT.EDU (Will Fiveash)
Tue Mar 23 16:30:46 2010
Date: Tue, 23 Mar 2010 15:29:41 -0500
From: Will Fiveash <will.fiveash@oracle.com>
To: Nicolas Williams <Nicolas.Williams@Sun.COM>
Message-ID: <20100323202941.GB14765@sun.com>
Mail-Followup-To: Nicolas Williams <Nicolas.Williams@Sun.COM>,
Jeffrey Hutzelman <jhutz@cmu.edu>,
MIT Kerberos Dev List <krbdev@mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20100323190048.GQ21244@Sun.COM>
Cc: MIT Kerberos Dev List <krbdev@mit.edu>, Jeffrey Hutzelman <jhutz@cmu.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, Mar 23, 2010 at 02:00:48PM -0500, Nicolas Williams wrote:
> On Tue, Mar 23, 2010 at 11:51:41AM -0700, Jeffrey Hutzelman wrote:
> > --On Tuesday, March 23, 2010 12:31:09 PM -0400 Greg Hudson
> > <ghudson@mit.edu> wrote:
> > >Can I have a bit more information about what Sun's pam_krb5
> > >implementation wants to do with the prompt types? We can probably add
> > >these three once I understand the need for them.
> >
> > I don't speak for Sun, but...
>
> ... you did a good job :)
>
> > It's important that PAM modules be able to distinguish prompts for
> > multiple things from each other, so that they can correctly
> > associate prompts with previously-collected replies when retrying an
> > operation after a conversation function returns PAM_CONV_AGAIN.
> >
> > In addition, as the PAM framework's ability to pass
> > previously-entered responses between modules improves, it is
> > important for PAM modules to be able to tell what a prompt is for,
> > so they can convey it correctly to other modules. It would be bad
> > to record the answer to a PIN prompt as if it were a password; we
> > have recently discussed the implications of such confusion.
>
> +1
>
> Will needs to distinguish PIN from password at all costs, and the
> current preauth promt type does do that, but he also needs to
> distinguish "insert token" (in response to which the module should NOT
> send a PIN) from "enter PIN", and, ideally, we should have at least a
> different prompt for "enter PIN" vs. "enter PIN on your token's PIN
> pad" (again, the module should not respond to such a prompt with a
> cached PIN).
Yes, what Nico and Jeffrey write is correct. In addition there is a
situation where our pam_krb5 module must restrict what is prompted
for (it must not prompt for a password, this is left to the
pam_authtok_get module).
--
Will Fiveash
Oracle Office x64079/512-401-1079
Austin, TX, 78727 (TZ=CST6CDT), USA
Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com
http://opensolaris.org/os/project/kerberos/
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
