Vici prompt

[Thermi]

Quick'n dirty implementation of a callback for VICI in credential_manager_t so VICI clients can provide shared credentials, e.g. PINs and passwords via VICI. Useful and necessary for implementing a desktop client that supports TOTP.

[Thermi]

Eh, well, I didn't touch libptls or others, so there's still work to be done.

[tobiasbrunner]

Did you miss callback_cred_t?

[Thermi]

No, because callback_cred_t doesn't support dynamic or any kind of callback mechanism that provides either ID information, or anything received by the xauth or eap plugins.
Or am I wrong? I don't see how anything like that is possible with callback_cred_t, or their use in credentials_manager_t (because there they are in thread local sets).

[tobiasbrunner]

Not sure what you are referring to. The callback receives the same information that's passed to the create_shared_enumerator() of a full credential set (type, local and remote identity). By the way, in the android-pw-callback branch I integrated similar on-demand functionality into an instance of the latter ("android: Query user if no password is configured" commit).

[Thermi]

Well, okay, I did not know about the type. At the very least, to get the peer's text message to the callback, it needs to be passed to the credentials manager, so some code change in libcharon is needed anyway. Would it be acceptable to rewrite the code to make use of callback_cred_t? It'd result in swanctl and VICI gaining the ability to provide credentials dynamically and the server message (might be customized on specific commercial VPN peers). If several authentication rounds are used, the message can be important (e.g. if the account uses MFA, the second round on the initiator side might prompt for a TOTP. The user needs to know a TOTP secret is wanted, not the password for the user account).

[tobiasbrunner]

At the very least, to get the peer's text message to the callback, it needs to be passed to the credentials manager, so some code change in libcharon is needed anyway.

Can't the message be determined before and passed to the callback as data? Or could it be generated as needed in the callback (e.g. based on the passed data and maybe context information that could be retrieved via bus_t::get_sa)? Where secrets are enumerated it might not be obvious what purpose they have (in the larger picture) or what format/language the message should be (and requiring every call site/plugin to provide potentially the same messages doesn't seem ideal). Also, blindly passing messages/data received from the server (what authentication methods even provide that?) to a vici client/console sounds like a potential security issue.

[Thermi]

No, the message is dynamically generated by the server. E.g. eap-gtc supports that. And so does XAUTH (but IKEv1 is deprecated anyway). The message is part of the challenge, so it's available at the time the challenge is processed.

The context and language should be evident from the message sent by the other peer, so that's no issue. I think we can safely assume only UTF-8 or ASCII is part of the message, no UTF-16. We only need to make sure no weird formatting characters are in there, or NULL bytes. At the moment, the message is simply not processed by strongSwan and strongSwan itself sends out a static message. See https://tools.ietf.org/html/rfc3748#section-5.6:

     The Generic Token Card Type is defined for use with various Token
      Card implementations which require user input.  The Request
      contains a displayable message and the Response contains the Token
      Card information necessary for authentication.  Typically, this
      would be information read by a user from the Token card device and
      entered as ASCII text.

For XAUTH, this is relevant https://tools.ietf.org/html/draft-beaulieu-ike-xauth-02#section-5.2 and https://tools.ietf.org/html/draft-beaulieu-ike-xauth-02#section-6.2, specifically the XAUTH-MESSAGE attribute.

Generally, other authentication methods might need user visible messages, too.

[tobiasbrunner]

Yeah, I saw that we print the XAuth message to the log (after running it through chunk_printable()). As you noted, the message in EAP-GTC requests is currently just ignored. I guess we could sanitize that too and pass it to the get_shared() (this is the main entry for user passwords) and create_shared_enumerator() (called by the former and where the secrets are provided) methods of credential_manager_t and credential_set_t. There could still be issues regarding the formatting (e.g. whether the message ends with a : and/or spaces). I pushed something to that effect to the gh201-shared-msg branch. The only user so far charon-cmd.