[Bug 2652] PKCS11 login skipped if login required and no pin set

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #6 from Jakub Jelen <jjelen at redhat.com> ---
Created attachment 3124
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3124&action=edit
allow deferring the PIN prompt to reader keyboard

Well ... the pkcs11_open_session() is called from pkcs11_add_provider()
and that is called either from ssh, ssh-pkcs11-helper or from
ssh-keygen.

 (1) The ssh and ssh-keygen call this function with NULL pin. The ssh
asks for the PIN later. This is fine.

 (2) The ssh-pkcs11-provider and ssh-keygen (CA signing) call this
function directly with pin as provided by user (can be zero-length
string), and in the second case can be also NULL (preferred way).

Given that, the first condition is certainly not useless. It makes
sense to fail before opening session if we know that we can not provide
a pin. There is possibility that the PIN provided by user (through
ssh-agent protocol) is empty string and in that case, we do not have
any way how to prompt for the PIN later. Theoretically, there is still
a way to ask using askpass, but it is not implemented at this moment.

But the other part is true. The interactive-login already detects the
CKF_PROTECTED_AUTHENTICATION_PATH flag, that is used for logging into
the token from reader keypad.

I believe the same thing should be also supported in the ssh-agent
process, but since the pin prompt is in different process than the
actual connection to PKCS#11 library, the user just needs to submit
empty PIN and it needs to be detected later in ssh-agent, but certainly
not based only on the PIN value, but on the proper flags of the token.

In the case of using reader keypad, the pin should be a NULL_PTR as
recommended by specification [1]. Daniel, can you try the attached
patch (should apply on master), if it solves your problem?

[1]
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.